Instalé una copia nueva de macOS 10.13 en una unidad vacía. Después de iniciar sesión, verifiqué errores/fallas en Console.app. No esperaba ver ningún error y mucho menos fallas, pero Console.app mostró bastantes de ambos.
Reinicié pero esto no eliminó los errores y fallas que se muestran.
P: ¿Debería idealmente una instalación nueva de macOS no mostrar errores/fallas en Console.app?
Especificaciones/Detalles:
Algunos resultados de la consola (solo fallas, deduplicados y sin mensajes obvios relacionados con iCloud, inicio de sesión completo en pastebin ):
fault preference com.apple.apsd apsd apsd <private>: Preferences may have changed, checking for any relevant changes
fault apsd apsd Failed entitlement check 'com.apple.private.aps-client-cert-access' for <private>
fault apsd apsd Failed entitlement check 'com.apple.private.dark-wake-push' for <private>
fault xpc com.apple.apsd apsd apsd Interrupted connection to service <private>
fault apsd apsd Peer connection [pid=383] missing server
fault daemon com.apple.apsd apsd apsd Unknown environment '<private>'
fault daemon com.apple.apsd apsd apsd User <private> is not bootstrapped, loading persistent connections may fail
fault User Defaults Daemon com.apple.cfprefsd CoreFoundation cfprefsd rejecting read of { com.apple.SubmitDiagInfo, root, kCFPreferencesCurrentHost, no container, managed: 0 } from process 495 because accessing preferences outside an application's container requires user-preference-read or file-read-data sandbox access
fault User Defaults Daemon com.apple.cfprefsd CoreFoundation cfprefsd rejecting read of { kCFPreferencesAnyApplication, kCFPreferencesAnyUser, kCFPreferencesCurrentHost, no container, managed: 0 } from process 493 because accessing preferences outside an application's container requires user-preference-read or file-read-data sandbox access
fault User Defaults Daemon com.apple.cfprefsd CoreFoundation cfprefsd rejecting read of { kCFPreferencesAnyApplication, oa, kCFPreferencesAnyHost, no container, managed: 0 } from process 638 because accessing preferences outside an application's container requires user-preference-read or file-read-data sandbox access
fault User Defaults Daemon com.apple.cfprefsd CoreFoundation cfprefsd rejecting read of { kCFPreferencesAnyApplication, oa, kCFPreferencesCurrentHost, no container, managed: 0 } from process 638 because accessing preferences outside an application's container requires user-preference-read or file-read-data sandbox access
fault User Defaults Daemon com.apple.cfprefsd CoreFoundation cfprefsd rejecting write of key uuidOverrideDNU in { com.apple.rtcreporting, root, kCFPreferencesAnyHost, no container, managed: 0 } from process 495 because Operation not allowed
fault User Defaults Daemon com.apple.cfprefsd CoreFoundation cfprefsd rejecting write of key uuidRespectDNU in { com.apple.rtcreporting, root, kCFPreferencesAnyHost, no container, managed: 0 } from process 495 because setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access
fault default com.apple.iconservices iconservicesd iconservicesd Failed to move temp file <private> to <private> with error: <private>
Sí. Estos errores son esperados y normales.
Una falla en la que el código intenta conectarse a iCloud cuando lo tiene deshabilitado es perfectamente esperado, normal y rutinario. Incluso las cosas que suenan aterradoras o siniestras son en realidad puntos de código internos y no tienen nada que ver con la funcionalidad.
Yo diría, mire absolutamente la consola antes de tener un problema para que no se preocupe tanto cuando tenga un problema específico con una aplicación o función específica y luego traiga esa observación con ese mensaje de registro específico a la mesa en un nuevo pregunta y mira si el consejo general se confirma o si es algo que podrías aprender/arreglar.
Específicamente, en una versión inicial 10.X.0, es posible que espere ver muchos más de estos mensajes, ya que el nuevo código aún se está probando y demostrando en la vida real y una vez que el sistema se estabiliza, estos errores de depuración y soporte se cambian a ser opcional o de menor prioridad. Lo que el desarrollador cree que podría ser un "error" raro podría suceder miles de veces en la realidad y no ser tan importante para registrar y ciertamente no clasificar como "error"
Aquí están los recuentos de errores y fallas en mi MacBook que funciona al 100% perfectamente, sin problemas:
$ log stats
size: 589,735,560 bytes
2,484,914,791 bytes (uncompressed)
start: Sun Sep 10 23:27:15 2017
end: Wed Oct 11 11:03:43 2017
statedump: 6,902
events: [ total log trace signpost ]
[ 36,978,153 33,189,182 18,493 623,275 ]
activity: [ create transition action ]
[ 3,139,162 0 83 ]
log messages: [ default info debug error fault ]
[ 33,127,303 437,500 303 245,043 20,801 ]
ttl: [ 1day 3days 7days 14days 30days ]
[ 623,309 31,524,041 885,274 405,568 399,660 ]
Menos del 1% de errores y muchas, muchas menos fallas. El sandbox emite muchos mensajes cuando evita que las aplicaciones lean y escriban fuera del espacio reclamado y eso es algo bueno, en mi opinión.
Una herramienta beta muy interesante es Woodpile de Howard Oakley: busca analizar el volumen y el patrón de los mensajes para ayudar a determinar cuándo/si comenzó o terminó un problema y podría ser una herramienta muy útil para las personas interesadas en ver sus registros .
LаngLаngС