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.

One of the most common reasons for looking in the log is when an error occurs and isn’t reported sufficiently. It’s also probably the most common reason for frustration with the log, when you can’t identify the error you were looking for. This article explains why the log may not be a good place to identify the cause of errors.

Claude conned

Perhaps the best illustration of the difficulties faced by those using the log to investigate errors is in Claude’s attempt to diagnose problems with the Clock app.

First, it came across what it classed as a memory allocation error in the entry
00.968273 error com.apple.runningboard [app[application.com.apple.clock.1152921500311884024.1152921500311884029(501)]:1921] Memorystatus failed with unexpected error: Invalid argument (22)

Then it found and misinterpreted a cryptic entry from the kernel that also referred to memory
10.891949 kernel Clock[19237] triggered unnest of range 0x1e8000000->0x1ea000000 of DYLD shared region in VM map 0x5c946da0d472dbbf. While not abnormal for debuggers, this increases system memory footprint until the target exits.

It continued by misreading perfectly normal sequences of entries made by RunningBoard and FrontBoard, involving jargon such as assertion, as pathological cycles. Like someone who had skimmed quickly through a complex detective novel, Claude then jumped to the wrong conclusions.

Riddled with errors

Perfectly normal logs are full of errors, the great majority being expected or benign, and surprisingly few turn out to be reflected in what actually occurs. To demonstrate this, I took a log extract with a total of 25,159 entries excluding Signposts and found that 820 of them contained the word error in their message. So you can expect around 3% of all log entries to mention errors.

This is reversed when you look for entries classed as Error or Fault, which are usually rare and seldom contain information relevant to a problem you’re investigating. This is because many significant abnormal conditions and events are reported in entries that aren’t classified as Error or Fault, and often don’t include the word error in the message.

Process killed

The real error that Claude didn’t find (possibly because it wasn’t included in the submitted log extract) occurred when a key process, mobiletimerd, exceeded its memory allowance, so was killed. The diagnostic sequence of log entries for that ran:
03.099138 kernel process mobiletimerd [19118] crossed memory high watermark (15 MB); EXC_RESOURCE
03.099148 kernel memorystatus: mobiletimerd [19118] exceeded mem limit: InactiveHard 15 MB (fatal)
03.100180 kernel mobiletimerd[19118] Corpse allowed 1 of 5
03.100567 kernel 54578.846 memorystatus: killing_specific_process pid 19118 [mobiletimerd] (per-process-limit 0 0s rf:- type:daemon) 15360KB - memorystatus_available_pages: 1327431
03.100665 com.apple.opendirectoryd PID: 19118, Client: 'mobiletimerd', exited with 0 session(s), 0 node(s) and 0 active request(s)
03.100679 gui/501/com.apple.mobiletimerd [19118] exited with exit reason (namespace: 1 code: 0x7) - JETSAM_REASON_MEMORY_PERPROCESSLIMIT, ran for 110ms
03.100708 gui/501 [100015] service inactive: com.apple.mobiletimerd

To the knowledgeable human, that reads clearly, but doesn’t include general terms like error, so could well be lost on AI.

Process failed

This example should be more readily accessible in the log, but could be overlooked. This occurred when a Spotlight service tried to extract content from a text file that started with certain characters such as LG, resulting in an indexing failure:
30.946740 mdwrite Decoding error: Error Domain=NSCocoaErrorDomain Code=4864 UserInfo={NSDebugDescription=[private]} for [private]
30.951004 mds Decoding error: Error Domain=NSCocoaErrorDomain Code=4864 UserInfo={NSDebugDescription=[private]} for [private]

Error code 4864 is NSCoderReadCorruptError, implying that the presence of characters at the start of a text file may be triggering a bug in RichText.mdimporter, the importer module shipped in macOS that’s responsible for indexing plain text files.

Process halted

My third and final example comes from an examination of why Safari was failing to load and display a webarchive, and illustrates how macOS privacy and security features can halt a process that would otherwise complete successfully.

For Safari to load the main frame, it needed to obtain PolicyForNavigationAction approval. What happened is:
01.154639 com.apple.WebKit Loading Safari WebKit 0x14c19b818 - [pageProxyID=21, webPageID=22, PID=596] WebPageProxy::decidePolicyForNavigationAction: listener called: frameID=24, isMainFrame=1, navigationID=26, policyAction=0, safeBrowsingWarning=0, isAppBoundDomain=0, wasNavigationIntercepted=0
01.154642 com.apple.WebKit Loading Safari WebKit 0x14c19b818 - [pageProxyID=21, webPageID=22, PID=596] WebPageProxy::receivedNavigationActionPolicyDecision: frameID=24, isMainFrame=1, navigationID=26, policyAction=0
01.154666 com.apple.WebKit Loading Safari WebKit 0x14c19b818 - [pageProxyID=21, webPageID=22, PID=596] WebPageProxy::isQuarantinedAndNotUserApproved: failed to initialize quarantine file with path.
01.154666 com.apple.WebKit Loading Safari WebKit 0x14c19b818 - [pageProxyID=21, webPageID=22, PID=596] WebPageProxy::receivedNavigationActionPolicyDecision: file cannot be opened because it is from an unidentified developer.
01.154799 Error Safari Safari Web view (pid: 596) did fail provisional navigation (Error Domain=NSURLErrorDomain Code=-999 "(null)")

What should have happened instead is that the decision was approval:
00.740168 com.apple.WebKit 0xa4bda0718 - [pageProxyID=19, webPageID=20, PID=1035] WebPageProxy::decidePolicyForNavigationAction: listener called: frameID=4294967298, isMainFrame=1, navigationID=25, policyAction=Use, isAppBoundDomain=0, wasNavigationIntercepted=0
00.740172 com.apple.WebKit 0xa4bda0718 - [pageProxyID=19, webPageID=20, PID=1035] WebPageProxy::receivedNavigationActionPolicyDecision: frameID=4294967298, isMainFrame=1, navigationID=25, policyAction=Use
00.740233 com.apple.WebKit 0xa4bda0718 - [pageProxyID=19, webPageID=20, PID=1035] WebPageProxy::receivedNavigationActionPolicyDecision: Swapping in non-persistent websiteDataStore for web archive.

Although reported in an entry classed as Error for once, its consequences aren’t made clear in subsequent log entries.

Error reporting in macOS

When Apple replaced traditional logs with the Unified log in macOS Sierra, it made it clear that the new log wasn’t intended for advanced users or system administrators, but primarily for engineers. However, no provision was made for significant errors to be reported in any more accessible form. None of my three examples were reported directly to the user, who was left unaware of what had happened, and why.

This failure to report errors to users has only led to more bugs being ill-defined and unreported, and has done Mac users a great disservice by eroding confidence.

Strategy

Identifying the cause of an error using the log has similarities with solving a ‘whodunnit’ detective novel. There’s usually no shortage of suspects and clues, although many of those may prove misleading. Tracing a suspect’s whereabouts can often prove decisive in determining whether they were in the right place at the right time, and sometimes establishing how the crime happened is essential to its solution.

One big difference from detective fiction is being able to establish what is normal, and drawing comparison between a normal record of what should happen for comparison against an abnormal extract can be valuable.

Suggestions:

• Obtain a complete log record, without the use of predicates, saved either as a logarchive or a LogUI JSON file. Although you’ll find it easier to work with filtered versions, only a complete record has all the entries you might need.
• When possible, compare a ‘normal’ sequence of events with the abnormal record.
• Identify and trace subsystems and processes specific to the malfunctioning component(s).
• Identify and trace subsystems and processes with controlling roles, including LaunchServices, RunningBoard, TCC and security.
• Process IDs can be invaluable when tracing.
• Turn detective.

AI future

The Unified log might appear an ideal opportunity for AI approaches, but the reality is that we’re still a long way from achieving reliable interpretation by AI.

One severe limitation that’s often overlooked is that current techniques don’t fare well at the scale required. Analysing even a modest log extract involves well over 250,000 tokens, comparable to assessments made by NovelQA. Whereas human performance with those models exceeds 90%, few AI systems can attain more than 70%, and in some cases fail to reach even 50%.

Maybe one day, but for the moment at least humans are likely to remain best at using the log to identify the cause of errors.

Decades ago, a Chinese village became an official symbol of revolutionary “self-reliance.” The slogan hasn’t changed, but nearly everything else has.

Diagnosing problems using the Unified log is a complicated business that requires understanding, insight, experience and a systematic approach. As few of us feel competent to wade through thousands of log entries trying to spot where things go wrong, this might seem an ideal opportunity for the use of AI. I’m very grateful to one of our regular readers for the opportunity to demonstrate how Claude coped with diagnosing a troublesome problem they’ve been having with the Clock app in Tahoe.

Signs and symptoms

When you’re diagnosing any problem, you should start with a clear account of its signs and symptoms before even thinking of resorting to the log. A good physician may take an hour or more obtaining a full history and examining a patient before they start thinking about performing any special investigations. Even though signs and symptoms may not lead you to a diagnosis, they should help you direct your investigations to best effect.

In this case, although the Clock app is launching, when displaying some views the content is missing. We therefore agreed to capture the log from the moment of launch from the Finder until one of the problematic views displayed. That’s easy to achieve by double-clicking the app when the menu bar clock has just turned to display 00 seconds, then checking the time again when the view has been displayed. Add a couple of seconds to the latter to determine the period to view in LogUI.

What’s normal?

Recognising what’s abnormal in the log is only possible if you know what the normal looks like. It’s often perfectly normal to see error messages, but knowing which are relevant is more difficult. In this case, I cheated and obtained a matching log extract from launching the Clock app on another Mac running the same version of Tahoe, making it simple to compare the two.

An interesting exercise for the reader is to submit a perfectly normal log extract to AI, with a vague description like “problems starting the app”, and seeing if it reports that as being normal. I doubt that it would.

Preparing a log extract for submission to AI

LogUI can provide log extracts saved to Rich Text Format, preserving the entry fields, although I doubt whether any AI will be able to interpret those correctly. Perhaps the best route is to save the extract in RTF, and save that in turn as plain text. A longer way round is to:

• Save the whole extract as a JSON file, to preserve the whole record.
• Use the Search tool to display the entries you want to submit for analysis.
• Click on the Reduce tool to remove the unwanted entries.
• Save the remaining entries in Rich Text, then save that in plain text format.

That also allows you to submit a shorter extract.

Claude’s report

AIs like Claude are thoroughly professional in their reporting, even when they’re utterly incorrect. In this case, Claude’s report is headed Complete Analysis of the Problem, and appears a confident and detailed assessment presented logically. It first establishes:

• The App DOES Launch Successfully
• Main Issue: Continuous Assertion Invalidation
• Infinite State Loop
• Critical Errors Identified

supporting those with digested “quotations” from the log, although in fact most of them are rendered in Claude’s words, not those in the log entries themselves.

It then leaps on to give the Final Diagnosis that the Clock app:

• Launches
• Creates its scenes and interfaces
• Registers functionalities (alarm, stopwatch, timer)
• Fails to maintain the assertions necessary to remain active
• The system continuously invalidates its resource requests.

Those are embellished with appropriate and emoji.

Following those conclusions, it cites what it terms Key Log Evidence in support of that diagnosis. Among those are the following.

Critical Error at Launch

For this, it quotes part of the message from
00.968273 error com.apple.runningboard [app[application.com.apple.clock.1152921500311884024.1152921500311884029(501)]:1921] Memorystatus failed with unexpected error: Invalid argument (22)
and a similar entry.

However, it doesn’t point out that those are rapidly followed by
00.969966 com.apple.runningboard [app[application.com.apple.clock.1152921500311884024.1152921500311884029(501)]:1921] set Memory Limits to Soft Inactive (800)
00.970684 com.apple.launchservices LAUNCH: Successful launched 0x0-0x3b03b pid=1921 com.apple.clock '[private]'
which would appear to contradict this being a “critical error”.

Kernel Warning

Claude’s report next misquotes one of the log entries as reporting
Clock[19237] triggered unmask of range (1 of 16384:0000->0x1ce000000 of DVLD shared region in VM map 0x5c946dd8d4c72dbbf
when in fact the full entry reads
10.891949 kernel Clock[19237] triggered unnest of range 0x1e8000000->0x1ea000000 of DYLD shared region in VM map 0x5c946da0d472dbbf. While not abnormal for debuggers, this increases system memory footprint until the target exits.
It gives no reason for changing unnest to unmask, DYLD (which makes sense) to DVLD (which is nonsense), or changing the range given.

For interest, I used LogUI’s Gloss feature to submit that entry to ChatGPT for its explanation:
This log entry is a system notice from the kernel indicating that a portion of the DYLD shared region in the virtual memory (VM) map has been unnested. […] In short: The macOS kernel is reporting that the process Clock caused a part of the shared dynamic library cache to become private memory. This is expected behaviour when certain debugging or memory operations occur, but it will temporarily use more RAM until the process exits.

Continuous Assertion Cycle and Scene Management Loop

Claude then claims that the perfectly normal entries made by RunningBoard and FrontBoard demonstrate a continuous assertion cycle and scene management loop. Anyone who has read my account of RunningBoard would realise that is a misreading of what is both common and normal.

Claude’s Possible Solutions

Nearing the end of the report, Claude recommends four possible solutions:

• Reset system permissions: sudo tccutil reset All com.apple.clock
• Rebuild launch services cache: /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user
• Verify system integrity: sudo /usr/libexec/repair_packages --verify --standard-pkgs
• If everything fails: This could be a specific bug in macOS Tahoe with the Clock app that requires a system update.

The first is misleading, as TCC has nothing to do with system permissions, but privacy controls. Although Claude has made no comments at all on entries by TCC, I have checked through those thoroughly and there’s no evidence of any problem with that subsystem. The command recommended isn’t likely to do anything useful, either.

Despite Claude having provided no evidence of any problem with LaunchServices, its second solution is to perform a full reset of the LaunchServices registry (not cache), although I’m not sure the command given is correct for that. This used to be a popular panacea in the past, but is now more trouble than it’s likely to be worth. The last time I reviewed this for Sequoia, I wrote:
“Running either of those in recent versions of macOS including Sequoia is likely to wreak havoc, though. While this appears to be effective with the Open With… list, its effects on System Settings can be catastrophic. This can remove its entire contents, and even blow the wallpaper away. Normal function should start to return after restarting the Mac, but even then problems can persist.”

Yet Claude gives no warnings of any adverse effects.

The third solution given is the most puzzling. repair_packages was used to repair System permissions in versions of macOS up to El Capitan. It hasn’t been used since, makes no sense at all in Tahoe with SIP and the SSV, and that command no longer exists anyway. I find it surprising that Claude should be recommending a course of action from ten years ago.

The final recommendation is manifestly ineffective, as this problem has persisted across updates from 26.0 to 26.0.1 and now 26.1.

Nowhere does Claude recommend the obvious course of action to contact Apple Support.

Claude’s Summary

The slick summary rounding off Claude’s Complete Analysis of the Problem states confidently that its root cause “appears to be either:”

1. “A system-level bug in macOS Tahoe’s memory status handling for this specific app”
2. “Corruption in the app’s entitlements or sandbox configuration”
3. “A conflict between the app’s resource requirements and what the system is willing to grant”

with the parting comment:
The error code 22 (EINVAL – Invalid argument) in the memorystatus call suggests the app is requesting memory limits or priority settings that the kernel considers invalid for its configuration.

None of those comments is supported in reality, nor by the evidence in the log extract.

My final test was to compare the log entries that Claude singled out as being diagnostic of the problem it has ‘completely analysed’, with those from my Mac mini M4 Pro, whose Clock app works perfectly. You won’t be surprised to learn that, in those respects at least, the two logs are identical. For the avoidance of doubt, that includes the “Kernel Warning” and “Critical Error at Launch” entries that Claude considered diagnostic.

My Summary

When presented with a log extract, Claude misidentified and misread log entries, and introduced errors in reporting what it claimed were the most important diagnostic entries. Its recommended solutions were ineffective, unwise, or a decade out of date. Neither did it give any warnings for their adverse effects, or recommend contacting Apple Support.

This doesn’t say that AI can’t help interpret macOS Unified log entries, and can’t do better in the future. But I hope it demonstrates the reality of what it will do today.

Postscript

Following up on Claude’s suggested solutions, I can confirm that the suggested tccutil command is ineffective, and that Tahoe has removed the -kill option from lsregister “because it was dangerous and no longer useful”. As the third solution was removed years ago, that leaves only the last of its suggestions that is valid.

As I explained a couple of weeks ago, log entries come in four flavours: regular, activity, boundary and signpost. These types have previously been distinguished by a single digit in the entry. Although the latter two aren’t commonly used, boundaries because they’re uncommon, and signposts because they’re seldom useful, activities do need to be distinguished from regular entries. This new build of LogUI uses emoji to do that, and brings improvements in exported entries.

Log list

Rather than display a single digit for the type of each log entry, LogUI now uses an emoji:

1. regular entries are marked with a right-pointing triangle,
2. activities with a softball,
3. boundaries with a clapper board,
4. signposts with a round pushpin.

Those make it much easier to scroll down through entries looking for activities, for example.

Rich Text export

Those are also shown in extracts exported to Rich Text Format files. Those exports have been improved to more closely reflect entries as they’re displayed in LogUI’s window, including the new type emoji, with the addition of extra fields for signposts.

Copy

The other form of exported entries are those copied from the list, by selecting them in the window and using the Copy command. Rather than trying to copy the full text contents of all the fields, this has previously brought a selection separated using tabs. In this version, the fields are expanded and use a vertical bar | as a separator, to provide
date | level | category | sender | process | subsystem | message or signpostName

Where an entry has no data for that field, it’s left empty. As signpost entries don’t have message fields, and the other three types don’t have signpostNames, the last of those depends on the entry type. This should make copied signposts more meaningful.

For example, a short regular entry might provide
2025-10-19 14:48:00.385306+0100 | info | SDNearbyAgentCore | CoreUtils | sharingd | com.apple.sharing | Checking active FT call count: 0
an activity
2025-10-19 14:48:00.902644+0100 | | | RunningBoard | runningboardd | | state update
and a signpost
2025-10-19 14:48:00.435671+0100 | | tracing | SkyLight | WindowServer | com.apple.SkyLight | FrameLifetime

LogUI 1.0 build 77 for macOS 14.6 and later is now available from here: logui177
from Downloads above, and from its Product Page.

Enjoy!

Time is central to any log, and with the high performance of the Unified log it’s fundamental. It’s also one of its most confusing aspects, particularly when you add time zones, seasonal clock changes, and clock synchronisation.

Clock ticks

I believe each log entry includes the Mach absolute time (MAT) when that entry was made, and those form the log’s internal timebase. However, Apple doesn’t document that, there are alternatives such as Mach continuous time, and times exposed in the public OSLog API are limited to opaque Date structures rather than MAT. In contrast, the log show command can return a numeric field named machTimestamp that does appear to contain the MAT of that log entry.

The first complication with time is that MAT differs between Intel and Apple silicon Macs. While each increment in MAT represents one nanosecond in Intel Macs, in Apple silicon chips MAT ticks occur three times every 125 nanoseconds, or once every 41.67 ns. These are monotonic, in that they always move forward, so every subsequent tick count is greater than (or equal to) the previous ones, unlike wallclock time.

I have looked in detail at how this is reflected in times shown in the log when accessed by different methods, including that now used by LogUI. In practice, this means that the finest resolution of time in LogUI is 1 microsecond, which should suffice for almost every purpose.

Wallclock time

While MAT can be useful for measuring differences in time with great precision, it doesn’t tell you the time in terms of real-world clocks, or wallclock time. Conversion between those relies on data stored in opaque timesync files stored alongside log files. Those are used to provide a wallclock time for each log entry when it’s obtained either through the log show command, or the opaque Date structure in the OSLog API that LogUI relies on. It’s here we encounter all the complexities of the wallclock, such as time zones, seasonal time corrections, and corrections to synchronise with global time references.

Times shown in log entries also need to match those set in the log browser. In practice that leaves two options for times shown in log entries: express them in the local time when they were saved to the log, or in the local time when they’re extracted from the log. By default, the log show command adopts the former, as does Ulbow because it gets its log entries using that command tool, but LogUI converts all times to local time when the log extract is obtained. log show does have an option --timezone local to synchronise entries to current local time, but that’s seldom used.

Wallclock adjustment

The only time measure that remains unaffected by system wallclock time adjustments is MAT. No matter how a wallclock time is expressed, though, there will always be a hiatus and the risk of duplicate times being given, for example with consecutive entries of
08:26:16.140474+0100
08:26:10.043353+0100 === system wallclock time adjusted
08:26:10.044335+0100

If you’re using the log to measure time, and those measurements span a wallclock adjustment, you will need to make a manual adjustment to allow for that.

Time zone and season

When times of log entries are expressed using the local time applicable when those entries were written, changes in time zone and seasonal adjustments become confusing. For example, these entries were written when the wallclock was advanced by one hour in accordance with the start of British Summer Time:
2020-03-29 01:09:22.489149+0000 361080253974026
2020-03-29 01:09:22.489160+0000 361080253985232
2020-03-29 02:09:22.522734+0100 361080253990360 === system wallclock time adjusted
2020-03-29 02:09:22.522749+0100 361080254005593
2020-03-29 02:09:22.522913+0100 361080254170158
In each case, the wallclock date and time are given first, followed by the MAT (from an Intel Mac), demonstrating that the hiatus of one hour doesn’t affect the latter.

According to convention, Summer time adjustments across Europe are made at 01:00:00 +0000 (UTC). So in the Spring, clocks are put forward from 01:00:00 regular time to 02:00:00 Summer time. In North America, changes are made at 02:00:00 local, and usually on different days. Because of the way that macOS manages time, changes to the system clock will inevitably occur shortly after the officially set time, in that case nearly ten minutes later.

To avoid this confusion, LogUI expresses wallclock and control times using local time when those entries are extracted from the log. In that case, you’d see
2020-03-29 02:09:22.489149+0100
2020-03-29 02:09:22.489160+0100
2020-03-29 02:09:22.522734+0100 === system wallclock time adjusted
2020-03-29 02:09:22.522749+0100
2020-03-29 02:09:22.522913+0100
as you would obtain that log extract when British Summer Time was already in force.

Converting from Date values stored in log files to strings expressed in local time isn’t something an app would want to repeat constantly, for example on the fly when scrolling through a list of 50,000 entries. LogUI therefore converts each time into text when it fetches those log entries. If you then save the log extract in JSON format, those times remain in that local form, and aren’t converted again if you open that file in a different time zone or seasonal time correction. If you want to retain times in their original format, so they’ll be converted into a later time zone, for example, save the log as a logarchive, to ensure that each time will be converted into text using the local time applicable when the extract is fetched from that logarchive. That should affect few users, and only in unusual situations.

Key points

• The Unified log appears to record times in Mach absolute time, and convert those to wallclock format when accessed.
• By default, the log show command, and apps like Ulbow that use it, give the wallclock time adjusted to local time when each log entry is written. That can result in confusing time sequences.
• LogUI expresses all times in local time when log entries are extracted from the log. That makes its handling of time independent of seasonal changes, and more consistent.
• Periodic wallclock adjustments affect all wallclock times, and may need to be allowed for when measuring times from log entries.

The greatest challenge in using the Unified log is how to navigate its many thousands of entries, to find those you want to read. Success depends on the combination of two aids: time and waypoints (or landmarks).

Time

No matter how you obtain log extracts, you need to know when to look for those entries. The more precisely you can work out the time of interest, the quicker and easier it will be to locate the entries you’re interested in. While the log command offers alternatives, LogUI works throughout using the local time applicable when you access the log, allowing for your current time zone and any seasonal adjustment to it, when accessing the live log in that Mac.

However, the underlying times given in log extracts are those recorded by the Mac or device whose log you’re accessing. If its system clock was five minutes slow when those entries were written to its log, then you need to allow for that. For example, when I first started my Mac yesterday its clock might have been 1 minute slow. An event that occurred at 10:56 yesterday by the room clock would therefore appear in the log entries for 10:55.

One important time you can discover is the boot time of the Mac. Mints offers a Boot button to retrieve boot times over the last 24 hours. If the logs were written by a different Mac or device, then you’ll need to search for the time of that last boot. Fortunately the first two log entries are easily recognised:
11:41:37.562774+0100 === system boot: D3CEA9B4-F045-434D-8D12-C6E794A02F14
11:41:42.758780+0100 kprintf initialized
The long gap between the first two entries is accounted for by the firmware phase of the boot process. If necessary you can search for a message containing === (three equals signs). Mints provides the time of the first of those for each boot, and its UUID.

There are two occasions when time can become confusing, when clock corrections are applied, and when clocks are moved forward or back to add or remove summer or seasonal time changes. Fortunately the latter only change twice each year, although when they do, you really don’t want to see what happened in the log, and those changes aren’t even applied at a predictable time.

Clock corrections, like kernel boot, are readily found by the === text in their message. They normally happen in pairs, with the first correction the larger, and the second often far smaller. Here’s an example seen in consecutive log entries:
08:26:16.140474+0100 /usr/libexec/sandboxd[80] ==> com.apple.sandboxd
08:26:10.043353+0100 === system wallclock time adjusted
08:26:10.044335+0100 Sandbox: distnoted(72) deny(1) file-read-metadata /private
08:26:10.044601+0100 2 duplicate reports for Sandbox: distnoted(72) deny(1) file-read-metadata /private
08:26:10.044606+0100 Sandbox: distnoted(72) deny(1) file-read-metadata /Library
08:26:10.089204+0100 === system wallclock time adjusted
08:26:10.091850+0100 started normally

The first adjustment dropped the clock back by 6.1 seconds, from 08:26:16.140474 to 08:26:10.043353. This means that you’ll see times of 08:26:12 both before the correction and afterwards. The second adjustment, from 08:26:10.044606 to 08:26:10.089204, was far smaller at 0.045 seconds, and at least went in the right direction.

The most substantial clock corrections are made shortly after booting. Although macOS does make them later, the size of those should be smaller.

Waypoints

Even working with times resolved to the second, those can still leave you browsing thousands of log entries. To locate more precisely you need details of one or more entries that will be sufficiently distinctive to focus in on a few dozen. These are waypoints for navigation.

LogUI provides three methods for locating these waypoints:

• using a search predicate to determine which log entries are extracted from the log;
• applying search text to filter out all entries that don’t contain a term;
• searching a rich text export of the log extract.

Predicates

These are best used when the time period of your extract needs to be relatively long, so would return a large number of entries. For example, if you can only narrow the time down to several minutes, and are looking for the time that a specific app was launched, you can look for that app’s job description when it’s created and written to the log by RunningBoard.*

Over a period of two minutes, RunningBoard might write thousands of entries in the log, so looking for your app’s job description among them would be time-consuming. Set the start time and period to cover the whole of the time you want to search, then set a predicate for the subsystem com.apple.runningboard.

When LogUI fetches that log extract, there might still be over 2,000 entries, so now is the time to apply search text to filter those further.

Search filter

To filter those 2,000 entries and show only those containing job descriptions created by RunningBoard, enter the text constructed job in LogUI’s search box, with its menu set to Messages, and press Return. You’ll now see that list reduced to just a handful, and looking through them you can discover exactly when your waypoint occurred.

My example for this article starts with a period of just 2 minutes, in which there were more than 100,000 log entries.

Using the com.apple.runningboard predicate whittled those down to 13,443 entries.

Searching within those for constructed job left me with just 8 entries to look through.

Search rich text

Sometimes you can’t devise the right combination of predicate and search filter to discover what you’re looking for, which might be an error reported in a subsystem or a process that you can’t identify. One good way forward is to narrow your log extract as much as you can, then save the extract as Rich Text, open that in a suitable editor, and search through it for the word error. That will discover every log entry containing the word error anywhere, rather than confining it to the message text.

Using time and waypoints

Armed with your waypoint and the exact time of its entry in the log, you can now set that as the start time, set a period of a couple of seconds, and get a full log extract containing all the detail you might need. This should give you further clues to allow you to move through time using predicates and search filters to discover what happened. This is much quicker and less frustrating than trying to scan through thousands of log entries in search of vague clues.

Key points

• Use time and waypoints to find log entries.
• Mints’ Boot button gives times of each boot in the last 24 hours.
• Reduce the number of log entries returned using a predicate.
• Narrow those down using a search filter.
• Search all text by exporting the log extract as Rich Text.

* Sadly, the days of being able to access freely RunningBoard’s informative job descriptions in the log are over. As of macOS Tahoe, all you’ll see is the dreaded <private> of censorship. If you want to examine these now, you’ll have to remove log privacy protection first. Thanks, Apple, for providing such useful tools then rendering them next to useless.

For many years, I believed what the log command told me, that log entries could contain any of the 26 or more fields available, although they didn’t. It was only as I was developing utilities like LogUI that I discovered that log entries come in (at least) four types, each with its own format and set of fields. This article is a guide to those, and how they are displayed in LogUI.

Entry fields

Those available in the OSLog API are fewer in number than appear in log command output, and include some of limited interest. Those not exposed in LogUI include:

• store category, which is invariably disk storage here.
• format string, that used to format the contents of messages. This was introduced following serious security leaks in High Sierra.
• components, linking in with the format string.

LogUI displays each entry using the same order of fields and colour-coding. Although they can’t all be seen together in any single log entry, the overall sequence is:

Standard levels are given as text, and chosen from one of the following: fault, error, notice, info, debug, undefined. These are only used with Regular log entries, not other types. LogUI always includes debug level entries when they’re available.

The four types of entry are:

1. Regular
2. Activity
3. Boundary
4. Signpost.

Regular entries

These are normally by far the most common, and are seen throughout the processes and subsystems writing log entries. They normally contain up to the following fields:
datestamp, [1], activity ID, category, level, sender, process, process ID, subsystem, thread ID, message

These examples include:
datestamp, 1, activity ID, category, level, sender, process, process ID, subsystem, thread ID, message
which is fairly normal.

Activities

These mark specific activities, and vary according to the process and subsystem. Some are valuable waypoints, and all are recognisably shorter than most regular entries, containing only the following fields:
datestamp, [2], activity ID, parent activity ID, sender, process, process ID, thread ID, message

These are examples of one of the most valuable activities reported, indicating a mouse-click or tap. They’re also complete, as they consist of:
datestamp, 2, activity ID, parent activity ID, sender, process, process ID, thread ID, message

Boundaries

These are rare but instantly recognisable because of their brevity. They consist of just three fields:
datestamp,[3], message

Two of the most important are the announcement of the start of kernel boot:

and adjustment of the internal clock:

These are also easy to search for, as their message contains the distinctive === string.

Signposts

By default, LogUI extracts omit Signposts, but if you tick the Show Signposts box before loading log entries, they will also be displayed. In parts, they can outnumber regular entries, and are unlikely to provide you with meaningful information unless you know internal details of their process. Each Signpost adds three type-specific fields, shown after the process ID:
datestamp, [4], activity ID, category, sender, process, process ID, signpost ID, signpost name, signpost type, subsystem, thread ID

These examples come from the most prolific user of Signposts, SkyLight for WindowServer, and contain
datestamp, 4, activity ID, category, sender, process, process ID, signpost ID, signpost name, signpost type, subsystem, thread ID
Note there’s no message field, as their meaning is determined by the signpost fields.

Datestamps and times

The OSLog API doesn’t currently give access to Mach times, only to opaque Date variables. From those, LogUI’s datestamps give:
year–month–day hour:minute:second.microsecond+timezone

All times and time zones given are those current when LogUI obtains that extract, not when that entry was written. This can become extremely confusing when clocks change to and from {summer time, daylight time, daylight saving time, daylight savings time, DST}, and when passing through time zones, and great care is required when reading logs containing such corrections. LogUI tries to make this easier, but care is still required.

If you have used the log command, you may be aware that can return Mach times as ticks, offering precision down to the nanosecond. This currently isn’t possible when using the OSLog API, but given the relatively slow clock of Apple silicon Macs, it’s no longer as useful as it used to be with Intel’s nanosecond Mach ticks.

Censorship

By default, all data in message fields is censored to protect the privacy of the user. This replaces chunks of text with the dreaded <private>, and can render many entries devoid of any useful information. In recent versions of macOS log privacy can be removed by installing a profile. However, that doesn’t apply retrospectively, only to log entries collected after the profile has been installed.

Removing privacy also increases the size in storage of log entries, and may reveal sensitive information. As soon as you have completed acquisition of the logs you need with privacy removed, you should therefore remove the profile, to allow normal censorship to resume.

A suitably signed profile is here: enablelogprivatedata

To install the profile, unzip the archive into a convenient folder and double-click it. You’ll be informed by a notification that you need to review the profile to install it. Open System Settings and select Device Management in its View menu, or search for it. Follow the instructions given there to install and activate it.

Sadly, this doesn’t cover all censorship. Some systems require additional configuration changes, for example CFNetwork diagnostic logging. Jeff Johnson explained how to enable that, but Apple has since blocked that, and I don’t know of a practical alternative. In some cases, additional detail can be obtained by adjusting log settings.

Summary

A short practical summary of LogUI’s log entries is provided in its Help book.

As promised earlier this week, I’m delighted to offer a new version of my log browser LogUI that provides a Diagnostics Tool to help you understand log folders and discover any problems with them.

Open its window using the Diagnostics Tool command in the Window menu, and you’re offered four tools at the top.

The first, Get Info, performs a simple analysis on the files in the selected diagnostics folder. By default, that’s your current live log, in the path /private/var/db/diagnostics, in your Data volume. After telling you how many log files there are in each of its three main folders, and the number of timesync files, it reports the date and time of the oldest Persist log file, marking the start of the continuous log record, in this case nearly 4 days ago.

You can use these tools on any diagnostics folder you can access through its dialog. This includes Time Machine backups, external boot disks, and other bootable systems. Don’t click on the Open button, though, until you’ve selected the diagnostics folder in the view above.

Locating the diagnostics folder in a Time Machine backup can be interesting, but once you’ve found it, LogUI will happily check it for you.

The Catalogue tool lists all the tracev3 log files in the folders inside diagnostics, starting with those in Persist. It gives each file’s creation and modification timestamps, indicating the range for log entries within them, their size in bytes, and an estimate of the period that file covers.

The Analyse tool extracts information from each of logd‘s statistics files, with the number of log entries broken down in frequency order. If you tick the CSV checkbox, they will be delivered in CSV format, ready to import into other software such as a spreadsheet.

The last of the tools, Save Text, saves the contents of the window to a text file for your records.

Further information about locations used for log files is in this article.

LogUI 1.0 build 74 is now available from here: logui174
from Downloads above, and from its Product Page.

Enjoy!

By far the most common problem experienced with the Unified log isn’t its large number of entries, but a lack of entries. You go to check your Mac’s security using SilentKnight, or Skint runs its automatic daily check, and they can’t find any log entries recording XProtect Remediator scans. Since those are obtained by analysing the log for the previous 36 hours, when your Mac’s logs only go back 8-12 hours, entries for the last set of scans are likely to be missing. This article looks at why that happens, and how macOS maintains its log.

Traditional Unix-style logs are maintained according to their age. Every 24 hours, routine housekeeping procedures delete log files over a certain age, typically five days, in the process of rolling the log. Because the Unified log could over that five-day period have swallowed many GB of storage, its maintenance service logd deletes log records according to multiple criteria including the space they occupy, their age, and the type of entry. This is considerably more complex, and occurs in three phases, according to where the entry is stored.

Ephemeral entries

Log entries are initially written to memory, before logd writes most of them to permanent storage on disk.

The first substantial purging of entries thus occurs when logd decides which are ephemeral and won’t be written to disk. This can be seen by following the number of entries in a short period of high activity in the log, over time, and is shown in the chart below for a sample period of 3 seconds.

When fetched from the log within a minute of the entries being written, a total of 22,783 entries were recovered. Five minutes later there were only 82% (18,655) of those remaining. Attrition of entries then continued more slowly, leaving 80% (18,309) after 8 hours. Analysis suggests that over this period in which there were about 6,100 log entries per second written to disk, approximately 1,700 log entries per second were only kept in memory and never written to disk. That suggests about 22% were ephemeral, a proportion that’s likely to vary according to the origin and nature of log entries.

Persist entries

The great majority of log entries that survive to be written to permanent storage are kept in the tracev3 files in /private/var/db/diagnostics/Persist, where logd maintains them according to the total size of that folder, with a target of 520-530 MB. As each tracev3 file is up to 10.5 MB in size, that results in logd retaining about 50 files in that folder, although some are smaller than the maximum.

Two of my apps currently provide the datestamp of the start of the current collection of Persist log files as an indicator of the oldest log entry available from them: XProCheck, and Mints with its Logs button. This is a feature I intend adding shortly to LogUI.

However, not all log entries are stored in those Persist files. Looking back in time at total log entries available for a set ten minute period each day, you might see totals like:

• 1 day old 33,827 in 10 minutes
• 2 days old 98,534
• 3 days old 59,296
• 4 days old 10
• 5 days old 1
• 6 days old 40
• 7 days old 0
• 8 days old 358
• 9 days old 1.

Those for the last 3 days are almost all Persist entries, but older entries are those retained in tracev3 files in the Special folder.

Special entries

Fault and Error log entries are normally written to the tracev3 files in the Special folder, and may contain additional message content kept in the warren of folders and files inside /private/var/db/uuidtext. logd purges entries from Special files separately, and apparently on the basis of their type and content rather than size. As a result, the Special folder can contain many tracev3 files of sizes ranging from over 2 MB to just a few KB, with their size tending to reduce with age. Any log entries recovered from dates before the oldest Persist file thus must have come from Special files.

Although files stored in the uuidtext folder are small, there can be a great many of them, and total size of that folder can exceed 1 GB. Those too are maintained by logd.

Other folders and files

tracev3 files stored in the Signpost folder contain only Signpost log entries used for performance assessment, and are purged at a slower rate than Persist files, but not retained as long as Special files. The High Volume folder appears seldom if ever used. The timesync folder contains time synchronisation data, small files that normally cover the whole period of Special files.

The /private/var/db/diagnostics folder contains several other files, including the logs of logd and logd_helper, and most significantly pairs of statistical summaries written during log maintenance, named logdata.statistics.[n] where n is a number starting from 0, in both .txt and .jsonl (JSON) format.

Each time logd performs maintenance on a tracev3 file, or on associated uuidtext files, it records data about the files in the current logdata.statistics files, both as plain text and in JSON format. The most useful of these records occurs when a Persist tracev3 file is rotated from being the file into which new log entries are written, to being retained without further additions. That entry records:

• the name of the tracev3 file;
• the time of rotation, thus the time immediately following the last log entry to be made to that file;
• the total number of log entries in that file, for example 42,365,476;
• for the top 20 processes that wrote entries in that period, the number of entries, the percentage of total entries, and the path to the process, listed in order of number of entries.

For example, in that tracev3 file containing a total of 42,365,476 entries, the kernel might have written 13,095,296 entries, 30.9%, and be top of the list, while runningboardd might only have written 1,223,157 or 2.9%. These statistics can be valuable in drawing attention to periods when there were problems, and for discovering which entries are limiting the coverage of Persist files, making it impossible for apps to recover entries for XProtect Remediator scans, for example.

Statistics entries for memory rollovers can also be useful, as are those for Special file rotation, although the latter contain fewer entries than Persist files.

Extending the period of log coverage

Currently, there doesn’t appear to be any way to set logd‘s size allowance for Persist files. When the Unified log was first introduced, it wasn’t unusual for that setting to preserve full log records covering a period of up to 20 days. As more processes now write copious entries in the log, a Mac that’s left awake and running at all times may only retain the last 20 hours of Persist entries, or even less.

Macs that don’t need to be awake and running at all times can extend their log coverage by sleeping or being shut down, when of course no entries can be written. If that isn’t possible, you can write your own XML property lists to /Library/Preferences/Logging to limit the retention of specific categories of entry. However, experience shows that only achieves small extensions to time coverage. It’s also worth bearing in mind that disabling privacy protection in the log will increase the size taken by most log entries, so shortening time covered by the retained logs.

Perhaps the wisest and most effective way to extend the time coverage of logs is to discover the causes of excess entries and address those, although that’s inevitably the most difficult solution.

One little-used technique is to turn log records in backups into logarchives, enabling old log entries to be accessed days or even years after they have been written. As an example of what can be achieved, the log entries below were written eight years ago, on 26 September 2017, saved in a logarchive, and browsed using LogUI on 26 September 2025.

I will explain how to do this in a future article in this series.

Summary

• Log maintenance is a sophisticated managed process that discards log messages for several reasons, most generally to keep total log file size within limits, rather than removing entries purely on the basis of age.
• A fifth of log entries are likely to be ephemeral, and lost from the log within the first minutes after they’re written. If you want the fullest entries possible, obtain the log excerpt as soon as possible after its entries have been written.
• Most retained log entries are written in Persist logs, where tracev3 files are removed by age to keep their total size to just over 500 MB. Those should preserve log entries for hours or days after they’re written.
• Entries for Faults and Errors are stored in Special logs, where they’re kept for longer, sometimes for weeks.
• logdata.statistics files provide detailed statistics for log files as they’re rotated, and can tell you which processes wrote most entries.
• As logs aren’t written during sleep, or when shut down, allowing sleep and shutting down will extend the duration of log records.
• Time Machine and other backups can be used to recover old logs as logarchives.

从 2024 年的今天，回望 2019 年的 Apple 和 Ive 团队，我们会发现有些变化和趋势似乎是早已注定的。在过往的观察和分析中，我们所预言的事情正在成为现实和主流。常言道以史为镜可以知兴替，今天再看当时的 Apple 和 Ive 团队，关于产品的演进思路和设计策略的变化都早有端倪，也能预见在 AI 席卷的浪潮下，Apple 将会如何应对。

在这一期，你会听到：

—- 二十年前的专利文件：通体透光的 iPhone

—- 国产厂商和 Apple 在设计上的差异

—- 成功的设计：AirPods 只是剪掉线的 EarPods

—- 塑料手机的设计巅峰：iPhone 5c

—- 刘海与机器视觉：早早布局的 AI 伏笔

—- 未来十年的人机交互：人和人之间怎么交互？

—- 设计策略上的「S型曲线」体现在哪里？

—- 产品路径上迷路的 iPad

—- 光洁的划痕：是矫情还是哲学？

—- 史上最佳手机壳：iPhone 5c 的多彩硅胶壳

—- 拟物化的残党，现在理解扁平化的先进性了吗？

｜相关图片｜

查看更多图片和设计讨论：Mac Pro 2019

｜拓展阅读｜

如何评价 iPhone X 的工业设计？

交互的王，时代的狂！万字详解灵动岛的今生来世！

十年轮回？经典进化！工业设计师深入解读 iPhone12！

从技术寿命 S 曲线，看阳极氧化铝的设计

抽象的产品，用户「界面」的设计

如何看待 Evans Hankey 从 Apple 设计团队离职？

注定会离职的 Jonathan Ive 和科技产品的设计趋势

｜登场人物｜

苏志斌：工业设计师，车联网智能硬件产品经理 / 联创，《设以观复》作者

王汉洋：AI 行业从业者，多档播客主播，《拯救东北1910》《山有虎》作者

｜相关链接｜

若你所使用的播客客户端未能完整显示插图，或遇网络问题未能正常播放，请访问：

荒野楼阁 WildloG 的地址：https://suithink.me/zlink/podcast/

阅读设计相关的各类文章：https://suithink.me/zlink/idea/

｜其他社交网络媒体｜

苏志斌 @ 知乎｜SUiTHiNK @ 即刻 / 微博

苏志斌SUiTHiNK @ Bilibili / YouTube / 小红书

｜联络邮箱｜

suithink.su@gmail.com

欢迎在 小宇宙、Spotify、YouTube、Apple Podcast 收听本节目，期待你的留言。