MacOS – Fresh macOS install: Console.app displays errors/faults. Is that to be expected

consoleerrorhigh sierramacos

I have installed a fresh copy of macOS 10.13 on an empty drive. After logging in I checked for errors/faults in Console.app. I didn't expect to see any errors let alone faults but Console.app displayed quite a few of both.

I rebooted but this didn't get rid of the displayed errors and faults.

Q: Should a fresh installation of macOS ideally display no errors/faults in Console.app?

Specs/Details:

  • macOS 10.13 High Sierra (10.13 (17A365))
    • installed using Apple's Installer from the Mac App Store to an external HDD
    • Location Services: On
    • Share Mac Analytics: Off
    • Apple ID/iCloud is still turned off
    • macOS Volume: HFS+ on external HDD
  • MacBook Pro (Retina, 13-inch, Mid 2014)
    • Magic Keyboard connected (Bluetooth)
    • Magic Trackpad 2 connected (Bluetooth)
    • Network access using Wi-Fi (WPA2)
    • external HDD connected (2.5", USB 3.0)

Some Console output (faults only, deduplicated and without obvious iCloud-related messages, full log on 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>

Best Answer

Yes. These errors are expected and normal.

A fault where the code is trying to connect to iCloud when you have it disabled is perfectly expected, normal, routine. Even things that sound scary or ominous are actually internal code points and have no bearing with the functionality.

I would say, absolutely look at the console before you have a problem so you won't worry so much when you have a specific problem with a specific application or function and then bring that observation with that specific log message to the table in a new question and see if the general advice bears out or if it's indeed something you could learn / fix.

Specifically, in a 10.X.0 initial release, you might expect to see far more of these messages as the new code is still being tested and proved in real life and once the system becomes stable, these debug and support errors are changed to be optional or lower priority. What the developer thinks might be a rare "error" might turn out to happen thousands of times in reality and not be so important to log and certainly not classify as "error"

Here are the counts of errors and faults on my 100% perfectly working, no issues MacBook:

$ 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 ]

Less than 1% errors and far, far less faults. The sandbox issues a lot of messages when it prevents apps from reading and writing outside their claimed space and that's a good thing IMO.

One very interesting beta tool is Woodpile from Howard Oakley - it seeks to analyze the volume and pattern of messages to help figure out when/if a problem started or ended and might be a very useful tool for people interested in watching their logs.

Related Question