Several users have reported errors when apps such as T2M2, Consolation, Cirrus or Taccy go to look at their logs. This article is a short introduction to solving that problem: what should you do when accessing the log on your Mac returns an error? Thankfully, this is very uncommon.

Are you an admin user?

Soon after Apple first introduced the unified log, with macOS 10.12 Sierra, it suddenly restricted access to admin users. Normally, if a regular user tries to run a command for which they required elevated privileges, this returns an error. When trying to access the unified log, that doesn’t normally happen: you simply don’t get any log entries back when you ask for them.

The best answer is to switch to an admin account, and run the app or command from there. I have two tools, RunT2M2 and RunConsolation, which try to work around this from a regular user account, but they aren’t always as reliable as I would wish.

Are you accessing compatible logs?

Each version of macOS since Sierra has changed the format of its unified log, and these aren’t generally backward-compatible. If you’re trying to read a logarchive from a Mac running Mojave, you’ll find that doing so on Sierra just doesn’t work. My apps which access logs call on the local log command tool to retrieve log entries (there’s no other way of doing this): if that’s out of date for the format of the logs that you’re trying to access, it won’t work.

This also applies to dual-boot systems when running in the older version of macOS. To access the logs in the newer version, you must restart in that or a more recent version of macOS, so that a newer version of the log command is available. But Mojave’s log command should be able to access all versions of the unified log going right back to Sierra.

Are your log files where they should be?

Unified log files aren’t stored in folders named log or logs, but in dedicated folders tucked away inside the /var/db folder of your boot volume. In Mojave, you should have the following folders there:

• /var/db/diagnostics/HighVolume, which is often empty.
• /var/db/diagnostics/logdata.statistics.[n].text, one or more files numbered from 0 upwards.
• /var/db/diagnostics/Persist, the main folder containing tracev3 log files, of which there may be up to 50 or 60.
• /var/db/diagnostics/shutdown.log, a single file.
• /var/db/diagnostics/Signpost, containing many additional tracev3 files.
• /var/db/diagnostics/Special, containing even more tracev3 files.
• /var/db/diagnostics/timesync, containing numbered files, typically 1-10.
• /var/db/diagnostics/version.plist, a single property list.

Another important folder for the logs is /var/db/uuidtext, which contains many more folders which hold details of UUIDs which are referenced by the log files themselves.

The service daemon which maintains and rolls these logs is logd, which should be listed in Activity Monitor. Don’t be tempted to try to do its job for it and ‘tidy’ or clean those folders manually, as you’re almost certain to break them.

Are the tools broken?

The two tools which are essential to log access are the service daemon logd, which performs housekeeping of the log files, and the log command itself. If either is damaged or missing, the system can’t work properly. The best solution then is to download and install the latest Combo updater for macOS. Failing that, try re-installing macOS.

Starting from scratch

If you’ve tried everything else, it may be that your whole unified log system has fallen apart, and re-installing it is the only option. Before trying that, if you really want to trash all your logs until now, the Terminal command
log erase --all
will remove all existing unified log files and set them back as if a clean install of macOS, but there’s no undo, and those logs will be gone for ever.

The last ditch measure is of course a clean install of macOS, which has the same effect but also replaces log and logd.