macOS runs dozens, maybe even hundreds, of services. Some like logd run in the background all the time, while others are scheduled to run every now and then. The most prominent example of the latter are Time Machine backups performed by backupd, which should occur every hour. This article explains how those activities are scheduled.

The traditional service for running scheduled background activities in Unix is cron, and that’s what the first versions of Mac OS X shipped with. But Dave Zarzycki was busy designing and coding a replacement service for cron and a lot more besides: launchd, which arrived in Mac OS X 10.4 Tiger, in 2005.

In this new model, one of the early tasks of the kernel after it has been booted is to load launchd, which then becomes the master launcher and launches everything else, in conjunction with launchctl and property lists in LaunchDaemons and LaunchAgents folders in Library folders. In replacing cron, launchd took on the responsibility of running scheduled background activities too.

The first couple of years with launchd had their moments, as it took a while before it became reliable. Just over two years later, when Apple released Time Machine in Mac OS X 10.5, it was scheduled to make backups every hour using launchd. The disadvantage of that was that, like cron, launchd isn’t flexible on timing: the moment that it decides to run a large backup could coincide with intense user activity, resulting in slowing of response to the user and prolonged backup duration.

At some stage over the following years, before macOS 10.12 Sierra in 2016, Apple introduced a whole new system designed to schedule background activities more flexibly, Duet Activity Scheduler (DAS). This is related to CoreDuet, a sub-system concerned with monitoring environmental and process load conditions. DAS maintains a list of scheduled activities, and frequently evaluates those activities to determine which should be run next. It does that by scoring them, taking into account the window during which the activity should occur, its priority expressed in terms of Quality of Service (QoS), the current load on the CPU, and environmental conditions.

Those are combined to produce a score: when that exceeds a threshold, DAS decides to run that activity, and will in turn tell Centralized Task Scheduling (CTS) via XPC to run that activity. Once that’s complete, the next run will be scheduled with DAS, which puts that activity back into its scheduling list. This and other processes are summarised in the following diagram, based on what happens when scheduling routine hourly backups using Time Machine.

Most scheduled background activities in macOS are now managed by this combination of DAS and CTS, which has proved itself to be superior to fixed time intervals managed by launchd. macOS Sierra was an exception, because of a bug, probably a memory leak, which led to DAS failing to evaluate its list of scheduled activities after several days of continuous running. The effect was for all its scheduled activities, including automatic backups, to become very infrequent or cease altogether. That bug was fixed in High Sierra, but remains in Sierra as far as I’m aware.

Now that Big Sur can make Time Machine backups to APFS volumes, macOS continues to use this mechanism, summarised below.

Today’s macOS is of course more sophisticated than Sierra in terms of the environmental assessments made by DAS. These ‘policies’ can now include:

• application, 25.0
• battery level, 1.0
• boot time (how long since the last boot), 0.01
• call in progress (a carry-over from iOS), 2.0
• carplay connected (a carry-over from iOS), 0.01
• CPU usage, 5.0
• energy budget, 1.0
• memory pressure, 5.0
• network quality, 8.4
• power nap, 5.0
• charger connected, 10.0 or 20.0
• thermal, 5.0

where the figure given for each is a typical value of its weighting in the overall scoring system.

As I noted above, one of the significant factors when scheduling background activities is the QoS set for that activity. The great majority of these have the minimum QoS, so that when they’re scheduled to run on an M1 Mac, they do so on the Efficiency (Icestorm) cores. That’s why Time Machine backups occur at slightly irregular intervals, and when they do, they occupy the Icestorms and leave the Firestorms free for the user. That’s shown very clearly in the CPU load chart below, during which there was a large backup handled entirely by the four Icestorm cores.

It’s almost as if Apple designed DAS for the M1 chip.

Reference

Wikipedia on launchd