In the previous article looking at what happens in Sierra’s log after starting up, I gave some waypoints for general events which take place. This article focusses on the essentially undocumented management of activities by Centralized Task Scheduling (CTS) and Duet Activity Scheduler (DAS).

Just after 3 seconds following startup, DAS is initialised, with the message
Initializing DASDaemon...

About a second later (with just over 4 seconds elapsed since startup), com.apple.xpc.activity registers the changes which are occurring, with messages stating
User Active
FullWake:cpu disk net aud vid
resuming activities on transition
Time Change: Registered for time change notifications

Loading the DAS activity list

Following these, CTS starts to load DAS with activities, beginning with those which are run by root.

The first to be installed are two Time Machine backup activities: backupd-auto, the main backup service, which repeats every 60 minutes within a grace period of 30 minutes, and is not allowed when running on battery power; backupd-auto.dryspell, a non-repeating activity which runs at some time over the next day or so, follows.

Next are three AWDD items: awdd.trigger which has two activities, and awdd.publication; they are each run infrequently. They are followed by usbd.messageTracerLogging, which runs daily.

The next group of activities to be installed are concerned with system and security maintenance. These include:

• SoftwareUpdate.Activity, which is run every six hours
• security.syspolicy.rearm, which runs hourly
• periodic-weekly, which runs once a week
• periodic-monthly, which runs once a month
• periodic-daily, which runs once a day
• mobileassetd.metadata-update, which is run every minute
• icloud.findmydeviced.launch-on-reboot is run just once
• driver.ethcheck is run once only.

The three periodic- activities are the macOS equivalents of the traditional Unix daily, weekly, and monthly housekeeping tasks. In early versions of Mac OS X, these were run as scheduled tasks using cron, as is usual in Unix, so appeared in the crontab. When Apple moved away from cron and encouraged the use of launchd, they were ported across to that.

The problem with both cron and launchd for such housekeeping tasks was that they were normally timed to run at about 0200, when most Macs were shut down. When those Macs were started up later in the day, no attempt was made to catch up with routine tasks which should have been run earlier.

The current DAS and CTS mechanism should ensure that such tasks are performed at some time when the Mac is running, normally when their impact on the Mac’s use will be minimal, and they are good examples of the benefits of this relatively recent scheduling and dispatching system. Of course, with its new unified log, Sierra does not rely on its daily housekeeping to rotate the main log any more.

Then come activities whose purpose is little understood outside Apple:

• applessdbgrefresh.activity and applessdstatistics.activity, which are run infrequently
• coreduetd.knowledge and coreduetd.people, which run infrequently and are involved in Energy management heuristics
• revisiond.requeue_chunking, which runs every hour and is concerned with maintaining the app versioning system.

DAS fully active

With nearly 5 seconds elapsed since startup, and activities still being loaded into it, the DAS daemon is made fully active, with the announcement
_DASDaemon started

After that, the few remaining root-based activities are loaded up. These include:

• two or more activities from the metadata server mds which seem to run quite often on a demand basis
• quicklook.cloudThumbnailDatabaseCleanup, which presumably performs maintenance on a QuickLook thumbnail database, and runs infrequently
• noticeboard.update, which runs infrequently
• SymptomFramework.MaintenanceActivity, which runs infrequently and requires “Device Inactivity”.

It takes over 20 seconds to load these into DAS, and by about 23 seconds after startup, once the user has logged in, CTS is ready to load DAS with user-specific activities, which it does over the following 20 seconds or so.

User activities

The first user activities are part of the Core Suggestions service, and include: tourist.notify, suggestd.sendrtc, suggestd.vacuum, suggestd.persist-stats, suggestd.identityanalysis, suggestions.sqlentitystore.cacheprecomputation, suggestd.messagetracer, suggestions.harvest, and suggestd.trim.

After those is a ragbag of different services: quicklook.cloudThumbnailDatabaseCleanup, ProtectedCloudStorage.daily, photoanalysisd.backgroundanalysis, noticeboard.update, mediaanalysisd.fullanalysis, Maps.mapspushd.launchForAnnouncements, IMAutomaticHistoryDeletionAgent, followup.notify, FileStatsAgent, EscrowSecurityAlert.daily, diskspaced.daily, DataDetectorsLocalSource, cloudphotosd.pending-work.once, calendar.AlarmScan, CacheDelete.daily, bird.configuration-server-update, bird.sync, AOSHeartbeat.daily, ak.hb, AddressBook.ScheduledSync, syncdefaultsd, parsecd.flusher.background, and apsd.apprefresh.

There are further activities to support documents in iCloud and CloudKit: bird.sync, bird.stage.gc, bird.configuration-server-update, cloudkit.packageGarbageCollection, cloudkit.tokenregistration, cloudkit.operationInfoCacheEviction, and cloudkit.pcs.memorycache.evict.

The first of the geolocation services is loaded, in GeoServices.UpdateExperiment, after which multiple iCal synchronisation activities are added, each starting with ical.sync.x-coredata. To those are added calendar.suggestedevents.ignored and iCal.APSSubscriptionRefresh.x-coredata.

A series of activities with names starting with geod.XPCRemoteLogAdaptor.aid-types_ is added after those. Then comes another miscellaneous group, containing cloudphotosd.pending-work, PDCardFileManager.RevocationCheck, PDCardFileManager.CacheMaintenance, KeyboardServices.TextReplacementCKSyncTask, and storeagent.SoftwareMap.periodicReload.

The final group of activities is concerned with Siri, and consists of siri.xpc_activity.sync, siri.xpc_activity.service_maintenance, siri.xpc_activity.heartbeat, siri.xpc_activity.media-indexer, and siri.xpc_activity.metrics-sender. These are added by a little over 40 seconds after startup, by which time DAS and CTS are busy prioritising and dispatching their activities.

The new order

The services and activities listed here add to those which I detailed earlier. The mechanism by which they are added follows the pattern which I
proposed previously: in most, if not all, cases a LaunchAgent, LaunchDaemon or similar is started by launchd. That contains the code module(s) which perform the activity, and hands that over to CTS, which in turn passes it to DAS to manage as one of its scored activities.

Thus, over the last few years, Apple has transitioned OS X and macOS background and scheduled activities from being run at fixed times by the launchd mechanism, to a more sophisticated scheduling and dispatch system implemented in DAS and CTS. For Sierra’s log this is just as well, as unlike previous logs, launchd barely leaves a trace in the new unified log.

What is surprising is that in the scores of such activities that I have examined, not one has been produced by a third party: every single background activity has been owned by Apple.