When you start accessing Sierra’s new log, using Consolation or the log show
command in Terminal, you quickly realise how important its ‘predicate’ filters are. Wading through even a couple of minutes of log without any filtering is a tedious and exhausting experience.
This article (which I will maintain, and eventually link from Consolation’s Help Book) is a compilation of my experience in the selection of components for building filter predicates. I hope that it helps log use.
eventMessage
This searches the content of the message written to the log. Although it can be a good way of getting lots of hits, it can also return a lot of entries which are irrelevant. Unless you know quite specific terms to search for, it is best used in conjunction with another filter, such as processImagePath
, to narrow the search.
processImagePath
This searches the name of the parent process responsible for the entry, which is given by the full path to its executable code. So BBEdit.app is known as /Applications/BBEdit.app/Contents/MacOS/BBEdit. For apps this is usually excellent, but becomes less helpful for macOS components. Useful ones include all the major services (daemons) by name, and
/System/Library/CoreServices/Finder.app/Contents/MacOS/Finder
/System/Library/CoreServices/launchservicesd
/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow
for example.
senderImagePath
This is the full path to the actual code which is making the log entry, so for an app it is likely to be a framework or library rather than the more recognisable name of the app itself. Unless you know exactly which code might be causing the problem, it is usually harder to use and less useful than processImagePath
.
subsystem
Sadly, subsystem
and category
(below) are only available to apps and code which have been rewritten for Sierra’s new log. Consequently a lot of macOS and the great majority of third-party products do not support them. If you filter on the basis of subsystem
and the process you’re interested in uses only traditional logging, then you will not see its log entries at all. When it is available, though, it is probably the best filter of all.
Currently, support includes:
com.apple.bluetooth
com.apple.CFPasteboard
com.apple.clouddocs
com.apple.cloudkit
com.apple.coredata
com.apple.foundation.filecoordination
com.apple.mDNSResponder
com.apple.network
com.apple.processmanager
com.apple.securityd
com.apple.sharedfilelist
com.apple.sharing
com.apple.SkyLight
com.apple.spotlightserver
com.apple.TimeMachine
com.apple.useractivity
co.eclecticlight.blowhole
category
This has the same limitations as subsystem
. To distinguish between them: in
co.eclecticlight.blowhole.default
co.eclecticlight.blowhole
is considered to be the subsystem
, and default
is the category
. Categories are assigned by the code used to write to the log, and often use non-specific words which could apply to many different subsystems. At present, I have seen the following being used:
AllINFO
– this is the default category, so widely used
atomicfile
cache
default
entry
– CloudKit
error
exit
framework
integrity
LogFacilityCK
LogFacilityOP
– CloudKit
LogFacilityRequest
– CloudKit
LogFacilityTrafficBinary
– CloudKit
main
ocsp
policy
presenter
QueryTask
SDNearbyAgentCore
SecError - security error
security_exception
SFBLEAAdvertiser-NearbyInfo
TMLogError - TM log error
WirelessProximity
XPC
eventType
These include (numeric equivalents in parentheses):
logEvent (1024)
traceEvent (768)
activityCreateEvent (513)
activityTransitionEvent (514)
These are case sensitive. Their use limits the syntax of the predicate: if submitted as strings, e.g. “logEvent”, they will fail; if the predicate contains parentheses, they will fail.
messageType
These include (numeric equivalents given in parentheses):
default (0)
release (0)
info (1)
debug (2)
error (16)
fault (17)
These are case sensitive. Their use limits the syntax of the predicate: if submitted as strings, e.g. “logEvent”, they will fail; if the predicate contains parentheses, they will fail.
Thanks to @JPoForenso for help with eventType and messageType patterns.
Revised 24 June 2017.