Several of my utilities rely on being able to read log entries from your Mac. For most, this is the only way that you’re ever going to try to access the log. For a few this draws attention to potential problems, when the app discovers it can’t access the log and reports that as an error. This article explains what those errors mean, and what you can do to address them.

Log file layout

Files containing log entries are stored in two main locations in your Mac’s Data volume. The majority of them are in /var/db/diagnostics/, while additional and lengthier log data is stored in files named by UUID in /var/db/uuidtext/.

Those in /var/db/diagnostics/ are grouped into standard folders:

• Persist holds tracev3 files that contain regular entries, the most important;
• Special has similar files for shorter-life entries;
• timesync contains files that enable the entries in tracev3 files to be matched with clock time;
• Signpost holds tracev3 files for special entries for measuring performance;
• HighVolume is normally empty, but might contain entries during periods when they’re particularly frequent.

Unlike traditional Unix log files, macOS doesn’t keep logs for a fixed period such as five days, but the logd process maintains them constantly to keep their total size within set limits that can’t be altered. Thus the period covered by log entries depends on how frequently entries are written to the log. In extreme cases, that can fall to just a few hours, or could extend to many days, although typically it should be at least 24 hours.

SilentKnight

My most popular app that’s also most frequently run, SilentKnight runs a single check that relies on being able to access the log, to look for XProtect Remediator scan reports.

Each time you run SilentKnight, as it prepares to display its window, it runs four checks on the log, those detailed below for LogUI and XProCheck. If any of those fail, rather than warning you in an alert, it simply disables its check for XProtect Remediator scans, and reports XPR scans not checked. If those pass correctly but it can’t find log entries for the scans, it reports no scans in the last 36 hours instead.

There are complications, though. SilentKnight will only check those scans once a day. If you run it more often than that, it won’t repeat those log checks on the XPR scans, and simply informs you XPR scans not checked. It’s only if you see that for the first check of the day that message suggests there may be a problem with the log. You can also disable checking for XProtect malware scans in the app’s settings.

If you see the message XPR scans not checked when you first run the app, and you haven’t disabled that check, then it’s worth running one of the other log utilities to discover why.

XProCheck, Mints, LogUI

Because these apps are all about inspecting log entries, they incorporate more extensive checks and report errors in more detail. To fetch entries from the log, Mints uses the log show command, while XProCheck and LogUI access them directly through macOS. They all run the following checks when the app is starting up, before its main window is displayed, and will warn you in an alert. When you dismiss that alert, the app will quit to allow you to fix the problem before running it again.

Tests used are:
Is the current user an admin user? If not, the alert below is displayed.

Are there any log files in the Persist folder? If not, report that it can’t find any log files.

Are there any timesync files? If not, report that it can’t find any log timesync files.

Can log show retrieve at least 1 log entry from the last 2 seconds? If it can’t, report that it can’t find any log entries on your Mac.

Mints runs another as well:
Can log show get times in the correct format? If it can’t, report the log time format is incorrect and advise the user to set time to 24-hour format.

Fixes

First, ensure that your Mac isn’t deleting log files in /var/db/diagnostics/ or /var/db/uuidtext/. Some ‘housekeeping’ utilities have taken to doing that, but it saves little space, usually well under 2 GB, and removes a mine of invaluable diagnostic information.

You can get fuller information about what’s in those folders with the Logs button in Mints, which also tells you the date of the oldest log entry. The same information is available in LogUI’s Diagnostics Tool.

The usual recommendation for Macs that aren’t writing any files into the Persist or timesync folders is to perform a clean reinstall of macOS or, for Apple silicon Macs, to restore the Mac in DFU mode. However, you’d be wise to contact Apple Support in the first instance, as this problem has occurred before.

If your log records only go back a few hours, there’s no simple way to reduce the rate at which new entries are written to the log. This article suggests some general approaches, and this article explains how to use custom logging profiles.

I wish you success.

macOS gives you the choice of upgrading to the latest version, but each year makes it easier to upgrade by mistake. For those wanting to stick with macOS 15 Sequoia this has become even harder to get right. This article shows how you can install security updates without risking the upgrade, using my free utility SilentKnight. If you prefer you can do essentially the same thing from the command line.

Check for updates

Run the latest version of SilentKnight (2.12) and it will show you all the updates waiting for your Mac, including the Tahoe upgrade. Don’t, whatever you do, click on the Install all updates button at this stage, or try installing individual updates. Quit SilentKnight and open Software Update in System Settings to install the security update to Sequoia first.

Update macOS

Although you can download and install macOS updates using SilentKnight, it’s far better if you use Software Update to do that. Open that in System Settings and read what it offers very carefully.

Although you know you don’t want to click on Upgrade Now, you should also avoid clicking on Update Now in the expectation that it will update Sequoia to 15.7.2. Instead, click on the ⓘ button next to it to ensure that you only update what you intend.

In this window, uncheck the Tahoe upgrade, and tick macOS Sequoia 15.7.2 and Safari, then click on Update Now. Make a mental note of the large size of the Tahoe upgrade, and when the download starts, check that isn’t being downloaded. If it is, cancel it if you can, quit all other open apps, and shut your Mac down. Leave it a few seconds before starting it up and trying again.

Once the Sequoia security update has been installed and your Mac restarts into 15.7.2, open SilentKnight and let it check for updates again.

Install remaining security updates

In most cases, almost all the outstanding security updates such as XPR should now be installed as part of that macOS update. However, the one you’re likely to have to install manually is XProtect, and you also want to change SilentKnight so it doesn’t put you at risk of inadvertently upgrading to Tahoe.

Open SilentKnight’s Settings and uncheck Allow Install All Updates. That removes the button from its main window that you could click accidentally and initiate an upgrade.

Now open Terminal to install the outstanding XProtect update. Type the following command
sudo xprotect update
press Return and enter your admin password. That update should then be installed from iCloud. Check that by opening SilentKnight one last time.

SilentKnight confirms that all your security updates have been installed successfully. Although the Tahoe upgrade is still waiting there to catch you unawares, there’s now no Install all updates button. When you want to install individual updates such as XProtect, use the Install Named Update… command in the File menu. Paste in the Label of the update, such as XProtectPlistConfigData_10_15-5323, check that it isn’t the Tahoe upgrade, and click the Install Named Update button for each security update you want to install.

There’s one final trick you need to remember. When macOS keeps notifying you of the Tahoe upgrade, click on that notification away from its buttons to open Software Update, then close that window. That should ensure that macOS doesn’t try upgrading your Mac on the sly. If it does start downloading the Tahoe upgrade, quit all open apps and shut down. After a few seconds start up again and that upgrade should be forgotten. For a while, at least.

The most worrying feature of the current AI ‘revolution’ is how heavily it’s being promoted by everyone from vibe coders to governments. The best and most enduring revolutions are quiet, and bring change because they’re so compelling. If something new has to be heavily evangelised, look deeply inside it to discover why, and who stands to gain most from that snake-oil.

In the case of Mac firmware, change has been so underplayed that you might not have realised what has happened over the last decade. But Macs have gone from impending disaster in Thunderstrike 2 with many running old firmware known to be vulnerable, to Secure Boot and thoroughly reliable updates.

In 2015 Trammell Hudson, Xeno Kovah and Corey Kallenberg demonstrated a firmware worm they named Thunderstrike 2 that could have been abused to insert malware in boot flash storage in Macs. Had that been exploited it would have been disastrous. Apple acted quickly by hiring Kovah and Kallenberg, and a third firmware security researcher Nikolaj Schlej, but shortly after that Rich Smith and Pepijn Bruienne, then of Duo Labs, reported that many Macs were running outdated firmware. When Apple addressed Thunderstrike 2 it could thus have taken a year or more before most Macs would have been protected.

While Kovah, Kallenberg and Schlej were busy securing firmware, and developing eficheck to routinely screen it in every Mac each week, several of us were trying to work out how to maintain a list of current firmware versions for users to check their Macs against. The answer came in eficheck, which obligingly informed us of those it accepted, and we then discovered how to extract firmware update information from macOS updates, for which I’m eternally grateful to Pico for doing the work. From 4 October 2017 those version lists have been published on this blog.

Two years later, in July 2019, firmware version checking was automated in EFIcienC, the precursor to SilentKnight, and became one of the pillars of checking that your Mac was secure.

In my latest revision of that guidance I was at last able to write that firmware “no longer needs to be checked separately” from macOS. My latest list of firmware versions for macOS 26 Tahoe contains just two, compared with over 39 given for High Sierra. The concern of dozens of articles here over those ten years, firmware and its updating can now be trusted, as Macs have moved from EFI to iBridge (T2) and iBoot (Apple silicon), with modern macOS updaters that install firmware reliably. Well, almost every time.

While Apple implies this in its Platform Security Guide, this remains a quiet revolution that didn’t mean anything to marketing, nor was there any mention in a press release. Neither do Apple’s support notes explain how it makes Apple silicon Macs the first to run the firmware matched with their macOS, and to be fully downgradable using IPSW image files.

This journey hasn’t been smooth, and many will still remember models such as the iMac Retina 5K 27-inch Late 2015 (iMac17,1), which in certain configurations simply wouldn’t update its firmware. We discovered that some other Macs updated reliably until their internal storage was replaced. In the end it was the introduction of the T2 chip that made the big difference, bringing the same EFI and iBridge versions across the whole range of Macs.

Compare this with UEFI Secure Boot, an option that Apple wisely decided not to pursue. One recent vulnerability that could have allowed an attacker to deploy malicious bootkits in systems with Secure Boot enabled was reported by ESET in June 2024, but that vulnerable firmware wasn’t revoked by Microsoft until 14 January 2025. Another recent UEFI vulnerability affecting multiple models of Framework computers, BombShell, allows bypass of their Secure Boot, requiring firmware updates that are still being rolled out.

Sometimes we need to look back to see how far we have come.

If there’s one topic that needs explanation currently, it’s how macOS updates XProtect’s data. Let me try.

Up to and including macOS Sonoma

Until this changed in Sequoia, updating XProtect has been straightforward: its data is stored in a bundle named XProtect.bundle, in the path /Library/Apple/System/Library/CoreServices, on the Data volume so it can readily be updated. When you or macOS downloads and installs an XProtect update, it simply replaces that bundle with the new one. This is shown in the diagram below.

The source of those updates is Apple’s Software Update Service, through the Software Update pane in System Preferences or System Settings, the softwareupdate command tool, or an app like SilentKnight. Left to its own devices, macOS normally checks for updates soon after starting up, and once every 24 hours running after that.

Early Sequoia

XProtect in macOS 15 prefers not to use the XProtect.bundle in its old location of /Library/Apple/System/Library/CoreServices, instead looking for XProtect.bundle in its new location, /var/protected/xprotect.

However, when you or your Mac use the old update system, including Software Update, softwareupdate or SilentKnight, that still installs the update in the old location, where it won’t normally be used by XProtect when making its checks. What was supposed to happen in early versions of Sequoia was that at least once a day, macOS checked whether there was a newer update in the old location. If there was, then it should have automatically prepared and moved that to the new location in /var/protected/xprotect for XProtect to use.

If you wanted that to happen immediately, then you could run the following command in Terminal:
sudo xprotect update
then enter your admin user’s password. The xprotect command tool would then complete the installation of that update from its old location into its new one.

There’s also a second way that XProtect in early Sequoia could be updated, and that’s over a connection to iCloud. If that was used, then the update was installed straight into its new location, and didn’t change the XProtect bundle in the old location at all. Although Apple had used that earlier, all XProtect updates since the release of Sequoia came using the old Software Update system, so needed to be completed using the xprotect command in Terminal.

This is shown in the diagram below. The blue boxes show the old Software Update system, and the pink boxes are the new parts that ensure the update is installed in the new location.

Later, that changed and Apple started releasing updates via iCloud. By about macOS 15.3, xprotect update was no longer able to install XProtect in the new location, and that was only possible once that update had been released to iCloud, from where xprotect update could download and install it to the new location.

Late Sequoia and Tahoe

With the release of macOS 26.0 Tahoe, this changed again. Macs running the latest versions of Sequoia and any version of Tahoe (after 26.0 release) continue to update the old location in /Library/Apple/System/Library/CoreServices as before.

Updating the new location in /var/protected/xprotect can occur by two methods. A background service XProtectUpdateService can:

• ‘activate’ an update from the old location by installing a copy to the new location;
• use CloudKit to download an update available in iCloud and install it directly to the new location.

That service is scheduled to run once every 24 hours.

The end result can appear confusing, but is summarised in the diagram below.

There are two routes for XProtect data to be updated in the new location:

• XProtect in the old location is updated by softwareupdate, then XProtectUpdateService runs later and installs a copy of that update to the new location.
• XProtectUpdateService runs and detects an update available from iCloud, so downloads and installs that in the new location. That occurs even when the old location hasn’t been updated yet, but depends on the update being offered in iCloud.

Both of those updates run silently, and the only ways to check that the new location has been updated are to:

• check the version in /var/protected/xprotect,
• run xprotect version,
• use SilentKnight or Skint.

As far as the user is concerned:

• Updating XProtect in the old location is worthwhile, as it should enable XProtectUpdateService to update the new location from that.
• Running xprotect update in Terminal is only worthwhile if the new location hasn’t yet been updated, but that update has been released via iCloud, as confirmed using xprotect check.
• Either of the new update mechanisms should be run automatically within 24 hours of an update being released.

Summary

• In macOS Sonoma and earlier, XProtect updates come via Software Update, and are simple.
• In macOS Sequoia and later, XProtect updates are more complex, but should happen as if by magic within about 24 hours of their release.