dasd: the daemon that decides when your Mac does its chores

By CoreGuard · Aug 13, 2026 · 9 min read

What is dasd on a Mac?

dasd is the Duet Activity Scheduler daemon (/usr/libexec/dasd) — the macOS service that decides when deferred background activities actually run: Time Machine backups, software-update cleanups, security scans, sync passes, maintenance jobs. Apple ships no man page for it, but Howard Oakley's July 2026 analysis describes Duet Activity Scheduler (with its "consort" CTS, Centralised Task Scheduling) managing the background-activity queue — counting "at least 701 non-identical activities submitted" within the first ~72 seconds of a boot on macOS 26.5.2.

So when your Mac quietly runs a backup while you're at lunch, or postpones an indexing pass because you're on battery, dasd is the thing that made that call. It doesn't do the chores — it holds the calendar. Oakley also notes DAS and CTS are now "largely responsible for the work done by Efficiency cores" on Apple silicon: the background work you see on E cores mostly runs when this scheduler says go.

What dasd actually schedules

Almost anything macOS defers. In the single boot Oakley analyzed on macOS 26.5.2, the activities submitted to the scheduler in the first 72.5 seconds included Time Machine's automatic backup (com.apple.backupd-auto), software-update log cleanup (com.apple.softwareupdated.logs-cleanup), a firmware check (com.apple.AccessoryUpdater.UARP.firstBootFirmwareCheck), and XProtect's slow security scan (com.apple.XProtect.PluginService.agent.slow.scan) — over 700 distinct activities in total, before the desktop had finished settling.

Each activity comes with constraints, and dasd's job is to satisfy them without getting in your way. Oakley's example: a "Boot Time Policy" holds the first automatic backup until at least 300 seconds after startup. Multiply that by hundreds of jobs with different windows, priorities and power requirements, and you get the quiet choreography behind a Mac that seems to do its housekeeping exactly when you're not looking — and why so much of it lands on the Efficiency cores, which is a feature, not a fault.

Two relatives are worth naming so the family doesn't blur. coreduetd is the learning side of Duet — it studies how you use the Mac so the system can anticipate you. duetexpertd serves those predictions to features. dasd is the execution side: the calendar-keeper that turns "this job may run when conditions allow" into "run it now." Our full process map places coreduetd and dasd among its 31 entries.

What it looked like on one real Mac

I have no universal norm to offer: Apple publishes none, and one machine cannot establish one. What I can give you is a measurement. Three samples across a single day on the macOS 26.6 Mac this post was written on — mid-session, real workload — put dasd at 16.7 MB, then 16.1 MB, then 15.8 MB of memory at 0.0% CPU. The actual row from the last of them:

$ ps aux | grep '/usr/libexec/dasd' | grep -v grep
root  392  0.0  0.1  435350064  16176  ??  Ss  Mon09AM  5:42.85 /usr/libexec/dasd

Two things are worth reading off that. The number moves between samples, so treat any single figure — including mine — as one moment rather than a threshold. And the Mon09AM start matches this Mac's boot time (sysctl kern.boottime reports Mon Aug 10 09:37), so this instance has been scheduling for three days inside sixteen-odd megabytes. Momentary CPU blips when it makes decisions are expected. It verifies as Apple's by structure, not by name: the binary lives at /usr/libexec/dasd, the system LaunchDaemon is com.apple.dasd-OSX, and codesign reports identifier com.apple.dasd as an Apple platform binary (no Team ID — which is legitimate for Apple's own system software). There is no man page; that's normal too — Apple documents very little of Duet publicly.

The 2026 Golden Gate beta memory leak — dated and sourced

If you searched for dasd because Activity Monitor showed it eating your RAM in double-digit gigabytes, here is the honest state of that story. A MacRumors thread that started on June 25, 2026 — "Anyone else experiencing dasd memory leak on beta 2?" — collected about 31 posts across two pages reporting dasd at 10 GB to 70.6 GB of memory on macOS 27 Golden Gate betas 2 and 3, across hardware from an M1 iMac to an M4 Max Studio and an M5 MacBook Pro. Several reports name appstoreagent running alongside at 250%+ CPU, with dasd itself at 150%+, and duetexpertd mentioned in the same breath.

Beta users in that thread reported a temporary workaround: deleting the power-history database (sudo rm -rf /private/var/db/powerlog) and rebooting. Read that for what it is — beta-tester triage on a disposable install, not advice for a Mac you rely on. It deletes your Mac's power-usage history, it requires root, and the thread itself notes the relief was temporary: the leak came back. On a release Mac there is no reason to delete system databases over this.

Fix status, from the thread itself: through beta 3 the picture is mixed — two posters reported the leak gone on beta 3 in early July, one still saw it on beta 3 in mid-July, and another filed a Feedback ID. The thread's last word, on July 27, is a single user reporting they were "not seeing it in beta 4; might be fixed? (knocks on wood)" — hedged, one datapoint, and no report at all for beta 5. Probably improving; not confirmed fixed. I won't round that up. What the reports do establish: this wave is a Golden Gate beta phenomenon — if you're on release macOS (Tahoe 26.x) and dasd is at 20 GB, the documented beta reports do not cover your case, and it needs its own evidence. If you are on the beta: file it in Feedback Assistant, take the next beta when it lands, and treat the workaround as the thread describes it — temporary.

When dasd deserves attention

Apply the same reading as any daemon: shape, then symptom. Momentary CPU and small memory — ignore it, that's the scheduler scheduling. Memory in gigabytes on a release macOS, or CPU pinned high for hours with heat or battery drain attached — that's a plateau worth investigating, and no documented release-version pattern matches it, which makes evidence-gathering more valuable, not less. A read-only way to see what dasd has been deciding:

$ log show --last 30m --predicate 'process == "dasd"' --style compact | tail -20

That shows recent scheduling decisions without changing anything. What not to do: force-quit dasd in a loop. launchd brings it back — immediately or on the next demand — and the queued activities are still owed; you'll have reset the evidence and cancelled nothing. The other symptom direction matters too: if scheduled things never run — backups that don't happen overnight, maintenance that seems permanently deferred — the scheduler's conditions are where to look first (is the Mac ever awake, plugged in, and idle long enough?). Our overnight-drain post covers the adjacent question of what wakes a sleeping Mac to do such work.

How to check whether dasd is behaving on your Mac

1. Read the numbers. In Activity Monitor, find dasd (View → All Processes), and note Memory and % CPU. Near-zero CPU with memory in the low tens of megabytes is what the one macOS 26.6 Mac here showed — a reference point, not a threshold.
2. Verify it's Apple's by structure. The path is /usr/libexec/dasd; codesign -dv /usr/libexec/dasd reports Identifier=com.apple.dasd as an Apple platform binary. A same-named process anywhere else is not this daemon.
3. Classify the shape over hours. A brief CPU blip is a decision being made. Memory that climbs and never comes down — the beta-leak signature — is a plateau; note your exact macOS version before anything else.
4. Match against the known wave. On Golden Gate betas 2–3 with multi-GB dasd memory: it's the June–July 2026 bug wave — file Feedback, update to the newest beta, don't perform surgery on a Mac you rely on. On release macOS with the same picture: gather evidence (version, uptime, screenshot, the log command above) — that's a report worth making.

Where CoreGuard fits

CoreGuard is an honest, local-only Mac health monitor — it observes and explains, and never cleans or optimizes. For a process like dasd, that means the reading this post did by hand: live CPU, temperature and fan state with the top process named in plain English, and a per-minute history of system CPU, memory and temperature so a plateau is visible as a shape, not a feeling. It won't reach into the scheduler — nothing honest does — and it makes no network connections of any kind. The danger-visibility layer is free, and stays free.

Frequently asked questions