Few of us look in our logs often, but that doesn’t make them any less important. If you want to check whether Time Machine backups are working correctly, or if your Mac’s new anti-malware scans are occurring, there’s no real alternative. And if your Mac does get into trouble, sometimes its logs are the only place you’ll find the clues that lead you to a solution.

Recently it has become apparent that, in some Macs, the length of log retained at any time has become far too short, not uncommonly less than two days, and in some cases less than 24 hours. This occurs because, rather than retaining log entries for a set period, macOS keeps them down to a maximum size. The more rapidly new entries are added to it, the shorter the period covered by the log. This article looks at what you can do about it, and brings a new version of my free utility Mints to help.

Assessment

Mints version 1.10 adds a new button, to generate a report on the current state of the log. This includes the log period, as shown in the latest version of XProCheck, and additional information about the number of different types of log file. These are explained in its 35 page Help book.

Mints 1.10 is now available from here: mints110
from Downloads above, from its Product Page, and via its auto-update mechanism. Sadly, because of changes Apple has made in Xcode, this version no longer supports Sierra, but should work fine on High Sierra and later. I will leave version 1.9 available for those who want to run Mints on Sierra.

If the period shown for the log is long enough for your needs, you can be comforted by that result.

If the period is less than two days, then you’ll probably want to do something to address that. This appears more likely on Intel Macs that run awake 24/7, perhaps providing services to other systems. During quiet hours running, my production iMac Pro clocked up a median of over 6,000 log entries every minute, while my Mac Studio managed less that 4,000 entries per minute at the same times.

The first and most important check is that these log entries aren’t pathological, that there isn’t a problem causing them. If there is, you need to diagnose and fix that before going any further. Don’t turn the fire alarm off because the noise is annoying you!

The next step is to identify some subsystems that can be safely muted, and that needs a little exploration using a log browser like Ulbow. Be careful when you do this to disable Ulbow from either getting or showing signposts, as they’re handled separately, and don’t count as main log entries.

In my case, I found frequent runs of entries when macOS checked the status of its UPS, from the com.apple.iohid subsystem. These reflect what I should already be able to inspect elsewhere, so can be dispensed with. You’re also likely to come across many entries from com.apple.bluetooth that you’re little interested in. Other offenders might be FindMy and iCloud, which don’t seem to rest much overnight.

Ulbow has a chart view that should prove useful here. In both cases, inspecting five-minute sample periods showed high and sustained rates of log entry through the night. On my Intel Mac:

and on my Mac Studio:

Use the popup menu to look at individual subsystems too, and the tooltips on chart bars show the number of log entries in that period.

Draw up a shortlist of subsystems that you can, for the time being at least, lose from your log. This doesn’t affect those subsystems in the slightest: they’ll keep running just the same, but won’t flood your log with their incessant chatter. If you do want to enable their entries again, that’s easily done, although it won’t of course be retrospective. The cost of a cleaner log is that you won’t be able to inspect muted entries until you remove their mute.

Action

Log preferences are controlled by property list files stored in /Library/Preferences/Logging, where there are two folders, one for files setting preferences for Processes, the other for Subsystems. While you can create and install those property lists yourself, the simplest way to mute log entries for a specific subsystem is in Terminal, where the log config command creates, edits and removes those property lists for you.

For example, before changing anything for the com.apple.iohid subsystem, I looked at its defaults using
sudo log config --status --subsystem com.apple.iohid
which returned
Mode for 'com.apple.iohid' INFO PERSIST_INFO
meaning that all log entries of Info and Default status were saved in persistent storage, in the Persist log files. Although you can change the mode from Info to Default, that has relatively little effect. More effective is to mute those entries from persistent storage altogether, using the command
sudo log config --mode "persist:off" --subsystem com.apple.iohid

Checking the status then reports
Mode for 'com.apple.iohid' DEFAULT PERSIST_OFF

A few minutes later, with a com.apple.iohid property list setting that in /Library/Preferences/Logging/Subsystems, those entries stop appearing in the log.

If you’d rather craft your own property lists, this is how the log config command codes that mode:

These changes persist across restarts, until you return that subsystem to its default using log config, or remove the property list.

Apple provides limited information about these property lists.

Evaluation

Sampling further five-minute periods in the log using Ulbow can be useful. On my Mac Studio, in the hours after muting only com.apple.bluetooth, median log entries fell from 3,900 to 2,462, which is modest but should extend its log period usefully. Assessing my iMac Pro has been harder, because it remains my main production system, and after muting decided to peak at a log entry rate of over 34,000 entries per minute, apparently. Overall, though, it has been making fewer entries, and the log period reported by Mints is steadily increasing too.

So far, I’m impressed with the results of housekeeping on my log. I wish you even greater success.