Sometimes known as Diogenes or Havisham Syndrome, pathological hoarding is not uncommon. Where you wouldn’t expect to see it is in the Clock app bundled in macOS, where it can block its features from working. This article describes this bug that can affect macOS Sequoia and Tahoe. I’m very grateful for the persistent work of Michele, who has contributed much of this information.

Timer failure

Michele uses the Timers feature in the bundled Clock app frequently. Recently it has become temperamental, and now won’t display the contents of that view. He has spent a lot of time working with Apple Support, and trying various fixes, but the only way he has found to restore normal function is to use timers from a different user account.

He sent me two long log extracts collected from the moment he launched the Clock app, one with over 6,000 entries, and the other with more than 25,000. Despite Claude’s imaginary problems, I had been unable to discover anything wrong in either of them. Comparing them against a normal log extract there were no obvious differences or abnormalities.

Then someone suggested that he looked at com.apple.mobiletimerd.plist in ~/Library/Preferences, and removed the whole file. That immediately restored normal timer function, and now his Clock app is working perfectly again.

Service crash

Fortunately, one of the two log extracts he sent me contains the explanation. It transpires the Timers feature in the Clock app relies on mobiletimerd, and just over three seconds into that log record, the Clock app tried to fire up mobiletimerd to help it do its job.

mobiletimerd is a background process that relies on Mach IPC, so was launched by launchd to handle the user’s timers:
03.008036 gui/501/com.apple.mobiletimerd [19118] Successfully spawned mobiletimerd[19118] because ipc (mach)
03.062723 com.apple.mobiletimer.logging mobiletimerd starting...

About 0.03 seconds later, mobiletimerd had exceeded its 15 MB memory allowance. It was therefore terminated, leaving that service inactive, and the Timers view empty:
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

A later attempt to get mobiletimerd running again was delayed for 10 seconds, so occurred after the end of that log extract.

Hoarding

Michele had already discovered the cause of this excessive memory use, as its com.apple.mobiletimerd.plist file was nearly 7 MB. By the time that had been expanded into XML text, that could easily have accounted for 15 MB of memory. At first it looked as if this might have been damage or corruption of that property list, but it turns out that the file is fine, just far too big. So how could its preference settings become so large?

Each time you create and run a timer in the Clock app, mobiletimerd seems to append its details to the com.apple.mobiletimerd.plist file. In addition to arrays of MTAlarms and MTStopwatches, it collects MTTimers for every timer you create and run, but never seems to remove any. Thus the MTTimers list continues growing until mobiletimerd exceeds its memory limit and can no longer be run.

It’s not clear why this property list should store all these MTTimers. They’re not accessible to the user, who is only able to run the tiny subset still displayed in the window. Although none of the information in the property list is particularly sensitive, it does provide a full record of the times that each timer has been run, at least until the file occupies too much memory for the timer to function. It’s possible that mobiletimerd also hoards old MTAlarms and MTStopwatches that could result in similar problems.

Solution

The only workaround for those who use timers often is to periodically remove ~/Library/Preferences/com.apple.mobiletimerd.plist and so restore normal timer function. Although some of the solutions recommended to Michele would unintentionally have achieved that, they would also have involved a lot of wasted effort, and none can bring a permanent solution, so would have to be repeated every time that property list had grown too large.

Thus the only way to address this problem is for Apple to fix the bug. Michele has been told that Apple did fix a bug with that property list in Sequoia, although by the observations above it might have introduced a different bug.

Conclusion

If any part of the Clock app becomes dysfunctional, delete ~/Library/Preferences/com.apple.mobiletimerd.plist to see if that fixes it.

When you run a command tool you invoke its options in the command you enter. Those options are supplied each time you run the tool, and don’t persist. Apps are different, in having a GUI that usually offers the user options, and in relying on information that persists until you next run that app. Those are its preferences, settings or defaults, depending on how you look at them.

In traditional Unix, persistent preferences may be implemented as configurations, defined in a plain text config file. In classic Mac OS window settings and a great deal more were saved as resources, in the resource fork of the app or its documents. This resulted in one neat feature that’s seldom seen in macOS today, saving a document’s window settings to its file, so they will be reused the next time that document is opened.

One of the innovations in NeXTSTEP was the human-readable property list used to store serialised objects such as preferences. These consist of designated variables used by the app that are converted into a representation that can be expressed in text. For example, if an app lets the user decide whether to use US or metric units of measurement, that could be stored in memory as a Boolean variable, true or false, and serialised as the word true or false in a property list used to store the app’s preferences.

Contents

Accommodating all the preferences needed by an app usually requires a dictionary of those serialised values, each given a key for identification, and having an explicit or implicit data type. Thus, that user option might become
key: metricUnits
value: true, a Boolean with two possible values.

Mac OS X replaced the old NeXTSTEP format for property lists with two formatting schemes, XML and JSON, with XML the standard for app preferences. This is a file containing dictionaries of key-value pairs representing the serialised data:
<dict>
<key>metricUnits</key>
<true/>
<key>filePrefix</key>
<string>MyFile</string>
</dict>

Initially, all property lists were stored as plain text, but that’s woefully inefficient, so between Mac OS X 10.2 and 10.4 a more compact binary format replaced that, and remains the standard today, as implemented in the UserDefaults API.

cfprefsd

Although developers can handle their app’s defaults/preferences with their own code if they wish, macOS provides the defaults server cfprefsd, and that convenient API that is used by the great majority of apps. Under that, early in an app’s initialisation cfprefsd automatically opens that app’s preferences, then loads its key-value pairs to make them available to the app as it’s setting itself up.

cfprefsd is transparent to the developer, whose code simply accesses key-value pairs as they are required. cfprefsd may opt to keep the whole preference file in memory, and manage it however it sees fit. Thus the property list’s contents on disk may not represent those held in memory for the app, and any changes to the property list file may be overwritten when cfprefsd saves changed values from memory.

For a simple app, working with cfprefsd should also be straightforward. The app’s preference property list is opened by cfprefsd shortly after the app is launched, and the app’s code works through UserDefaults to make any changes to key-value pairs while the app is running. As the app is shut down, cfprefsd updates the preference file, and the user is once again free to change or delete that property list as they wish. However, there’s ample scope for that to become more complicated, or to misuse it.

Problems

Many apps today aren’t that simple in their structure, and use helper apps and other executable code that may still be running with access to the app’s preferences even though the main app is shut down. When the user thinks it’s safe to modify the contents of that property list, it may still be in the care of cfprefsd. The preferred approach then is to use the defaults command tool, which should work with cfprefsd rather than competing with it.

In the past, UserDefaults and cfprefsd weren’t always reliable, and some developers worked around their problems with a combination of the official API and performing their own direct manipulation of preference files. Those dangerous practices should have died out now.

Because an app’s preferences are accessed early as it’s being launched, any bugs or incompatibilities in those key-value pairs can have fatal effects before the app is fully open. For example, if a new version of an app reuses an existing preference key with a different data type, if it reads an old version of its preferences, that will throw an error. If that’s not handled well, that can cause the new version of the app to crash when launched.

Fortunately, all apps have to be able to create their own preference file for when they’re first run. There’s scope for further bugs there, when the file created isn’t updated to work with changed key-value pairs in a newer version of the app. That may result in an app that crashes when launched even when there’s no existing preference file saved, a problem for which there’s no workaround.

Finally, many apps have multiple preference files. If they run in a sandbox, the copy they use normally is in the Data/Library/Preferences folder in their container, in ~/Library/Containers. But they may also have a different property list in ~/Library/Preferences, and sometimes a master copy in /Library/Preferences as well. While I’m sure cfprefsd knows which to access, you may need to check by inspecting each file’s timestamps.

UserDefaults have improved significantly with SwiftUI, further integrating persistent storage of preferences. Although they can still trip up the unwary, provided you understand how they work and don’t try fighting the system, they should seldom cause substantial problems.

Further reading

UserDefaults (Apple)
Preferences and Settings Programming Guide (Apple) from 2013
Thomas Tempelmann’s Prefs Editor works with cfprefsd

For much of the last 25 years, macOS has had ill-defined and pervasive problems that have often been attributed to incorrect permissions in various parts of the file system. As a result, one of the common panaceas has been to repair those permissions, using procedures that have changed over those years.

Repair disk permissions

Until the introduction of System Integrity Protection (SIP) in 10.11 El Capitan, these problems generally resulted from files within the system acquiring incorrect permissions. To address this, Disk Utility had a feature to check and repair permissions of all major parts of the system, based on information contained in BoM files for system updates and installations. Repairing permissions in this way became one of the main panaceas in those older versions.

Although primarily intended to deliver better security protection, one of the benefits of SIP was that it largely prevented system files from gaining incorrect permissions, and the feature to repair them was removed from Disk Utility. In any case, because of SIP it was no longer possible for Disk Utility to change the permissions of files that were protected by SIP.

Reset user permissions

When macOS 10.12 Sierra was released, a different problem appeared, in which permissions were apparently set incorrectly not in system files generally, but in the user’s Home folder, specifically in ~/Library/Preferences. To address this Apple added a new verb to the already complex command tool diskutil, resetUserPermissions, and described how to use this in a support note. It’s perhaps no coincidence that this new problem appeared at about the same time that the cfprefsd service took on management of those preference files, and just one year after repairing disk permissions ceased.

At that time, the following problems were attributed by Apple to incorrect permissions in ~/Library/Preferences:

• changes to preference settings, particularly those for System Preferences, do not ‘stick’;
• changes made to the Dock do not ‘stick’;
• you are asked to authenticate when trying to move or alter some folders in your Home folder;
• when trying to save, you are told that the file is locked, or that you don’t have permission;
• Preview, TextEdit, and App Store apps (which are sandboxed) may crash when opened;
• alerts appear warning that the startup disk has no more space available for app memory;
• Safari or SafariDAVClient use large amounts of resources (memory);
• the Mac runs very slowly;
• iTunes cannot sync a device;
• there are problems with Photos or iPhoto libraries, including inability to import into the library, or forgetting the library each time the app is opened.

Most if not all of those could have been attributable to problems resulting from bugs in cfprefsd.

Repair Home permissions

Five years ago, Apple changed its recommendations to include running a new tool repairHomePermissions in Recovery mode, then re-installing macOS. Shortly afterwards, when Big Sur was in beta in June 2020, Apple withdrew that support note and all reference to repairing permissions, although the tool is still available in Recovery mode even on Apple silicon Macs.

Running repairHomePermissions from Terminal in Recovery launches a GUI app to repair permissions on a selected Home folder on the Data volume. However, I strongly recommend that you don’t try using this, as you’ll end up with the user being locked out of every folder in their Home folder. I have tried it three times in virtual machines, and each time I have had to discard that VM because of the problems it caused.

Delete a corrupt preference file

Regardless of those, there are still occasions when preference files can cause problems. These typically occur when a corrupt or damaged preference file causes an app or other code to crash, usually when it’s being launched. Although these are now far less common, and the SSV ensures that system files can’t become corrupted as they did in the days before SIP, it’s useful to know how to deal with them.

On most occasions, a preference file can be deleted in the normal way, either in Finder or Terminal, and it won’t return until that app is run again, as it won’t currently be managed by cfprefsd. The alternative is to use defaults:
defaults delete com.mycompany.appname
deletes all the key-value pairs within the preference file for com.mycompany.appname, leaving just the empty property list. This has the advantage that it can be used when cfprefsd is managing that file’s contents, so should always be reliable. Provided the app handles preferences correctly using UserDefaults, it should be able to repopulate the empty property list the next time that app is launched.

One significant caution is when working with files inside ~/Library/Containers,~/Library/Group Containers,~/Library/Daemon Containers and similar managed folders. Because these form sandboxes, macOS manages them differently and tampering with their contents is likely to have unintended effects, so is best avoided, although the defaults command should still be safe.

Summary

• Repairing disk permissions on system files ceased with SIP in El Capitan.
• Repairing permissions on Home folder preference files is no longer recommended by Apple, since Big Sur.
• Safe and robust deletion of contents of a preference file can be performed using defaults delete.
• Don’t tamper with files inside ~/Library/Containers, ~/Library/Group Containers and similar folders.
• Never be tempted to run repairHomePermissions in Recovery mode.