New and existing bugs in the unified log in Sierra 10.12.4-6

macOS Sierra 10.12.4 update brought with it some significant changes to the new unified log system which do not appear to have been documented anywhere. These have introduced new bugs, or features if you prefer to look at them that way. This article draws together what I currently know about them.

1. Log entries are only viewable when running as an admin user.

I have already described this elsewhere. If you are logged in as an ordinary user, any attempt – via Console or the log command in Terminal – to view log entries is unsuccessful. Neither returns an error, but just returns empty values. This also affects my free app Consolation, as that relies on the log show command.

2. Some previously-built os_log() calls no longer work properly.

Apps previously built with versions of Xcode prior to 8.3.2, in which os_log() is called to write to the log from Swift 3 code, have ceased working. The broken calls include those which format numbers into the log message, such as
os_log("Blowhole: %d", log: Blowhole.gen_log, type: type, number)

A log entry is still made, but the message is reported as being corrupt. This may render previously-built apps incapable of writing intelligible messages to the log in 10.12.4. The solution is to build the app again using Xcode 8.3.2, which appears to fix the problem and restores normal function of that call.

3. log collect commands still cannot be limited in size (bug since 10.12).

log collect --size
still doesn’t limit the size of the log archive generated. The --size option therefore remains functionless, and all log archives are limited only by the --start or --last arguments supplied.

4. Swift calls to write strings using %s in os_log() fail (bug since 10.12).

According to the limited documentation supplied, including that provided at WWDC 2016,
os_log("Blowhole: %{public}s", log: Blowhole.gen_log, type: type, string)
provides the only way of writing a dynamic string out to the log. However, passing a string to that invariably results in the string becoming lost, and the log entry then shows, e.g.:
[co.eclecticlight.blowhole.general] Blowhole: <decode: missing data>

However, thanks to Eddy Wong and Volodymyr Gorlov for pointing out that you can use %{public}@ instead, to write mutable strings in a log message, e.g.
os_log("Blowhole: %{public}@", log: Blowhole.gen_log, type: type, string)

Apparently, this was ‘discovered’ in October 2016, but has still not been made clear in the Swift documentation, nor has the original bug been fixed. It makes you wonder whether Apple really does want anyone to use Swift, or its much-vaunted unified logging system.

4. log show --info option functionless (bug since 10.12?).

Omitting the --info option for the log show command still results in Info messages being included in the excerpt. There seems no way to disable them, and including the --info option does not alter output.

If you have encountered any other bugs or changes in os_log, log, or Console, please let me know.

Last updated 30 July 2017.