In yesterday’s article about working in remote locations, I made the bold claim that Apple is making macOS more of a black box by moving key systems out of the reach of advanced users and support folk. One of those is macOS Sierra’s activity scheduling and dispatching system, used to run automated Time Machine backups and dozens of other background activities.

In most traditional Unix-family operating systems, running a task every hour, day, or week is accomplished using cron and configured using a crontab, a scheduling table which could, for example, be used to run those timed backups. Although Mac OS X and now macOS has retained support for cron and crontab, they have long been deprecated in favour of launchd, which is the most important process running in macOS after the kernel itself.

Using launchd is not difficult, and a matter of setting up a property list in one of the LaunchAgents or LaunchDaemons folders, following the instructions detailed in Apple’s guide. There are plenty of tools to help you do this, from Peter Borg’s generic Lingon to specialist apps which use this to customise Time Machine backup scheduling.

Much older versions of macOS have suffered problems with this system (and with cron), but many Apple and third-party products now put their trust in launchd working, and it very seldom disappoints.

Some time after 2011, it appears that Apple started moving its own scheduled and background services, like Time Machine backup, to use a novel dispatching system involving two services, Duet Activity Scheduler (DAS) and Centralised Task Scheduling (CTS), the latter being intimately related or a part of the lightweight communication and dispatching system XPC. No one outside Apple seems to know when this happened, as DAS and CTS are almost completely undocumented.

In Sierra, the DAS and CTS dispatching system now manages more than seventy activities at most times, one of which is Time Machine’s scheduled backups. However, in Sierra at least, this system has a bug which results in its breakdown: backups suddenly become irregular or stop altogether, and the other activities also become unreliable.

When this happens, it is tempting to revert to scheduling backups using the older launchd mechanism, and that will certainly restore them. But it does nothing for the seventy or so other services which the DAS and CTS dispatching system manages. It is a bit like a ‘get-you-home’ spare wheel in a car: it buys you time and sufficient mileage to get to a garage and get a new tyre.

For anyone needing to run their Mac continuously, particularly as a server, this is a devastating flaw. Although I and others have tried various solutions, the only way currently known to restore normal dispatching services is to restart the Mac. That is literally a showstopper for any server, and is more than inconvenient for many other Mac users.

With its lack of documentation, lack of controls, and lack of solutions, the DAS and CTS dispatching system is one such black box which has appeared in macOS. Whatever its benefits for the management of that Mac’s resources and its energy consumption – which appear to be Apple’s motivations for this system – it is now impacting on the Mac’s suitability for use as a server and in other applications. We’re reduced to the old remedy of turning it off and back on again.

Fixing the current bug in the DAS and CTS dispatching system is only a partial solution, although it is one which remains urgent and vital to many Mac users.

The DAS/CTS system is far more complex and sophisticated than either launchd or cron before it, and is therefore prone to further bugs and failures. If dispatching cannot be restarted successfully without restarting the whole Mac, then there will be issues in the future which will once again compromise servers and other systems.

By moving scheduling and dispatching of macOS’s background activities from launchd to DAS/CTS, Apple has significantly reduced the reliability of macOS, and limited the ability of advanced users and support folk to deal with its problems.