What is dasd on Mac?

Last updated: 2026-07-31

What it is

dasd is Apple’s Duet Activity Scheduler background daemon. It is started and managed by launchd, with the system service identified as com.apple.dasd and the executable located at /usr/libexec/dasd.

Its job is to register and evaluate deferrable background activities. Instead of letting every submitted task start immediately, dasd considers conditions such as power, temperature, user activity, and network state. It then decides when the app or system service that submitted the activity may begin working.

That distinction matters: dasd is a general scheduler shared by multiple system components and apps. It is not another name for Time Machine, Spotlight, iCloud, or any single synchronization service. Those services may submit or participate in scheduled activities, but the scheduler itself is a separate part of macOS.

Why it talks to the network

Some background activities declare that they need a network connection. A task may require any available network, an inexpensive connection, or an unrestricted connection. When evaluating such a task, dasd observes whether networking is available and considers conditions including connection cost and quality. It can then approve the activity, defer it, or wait for more suitable conditions.

What happens after approval depends on whoever submitted the task. The resulting connection might go to iCloud or CloudKit, Apple content or update services, or a third-party app’s own server. The process name dasd therefore does not identify the remote destination or tell you what content is being transferred.

In Apple’s published CloudKit example, dasd approves and triggers the activity, while the app process and cloudd perform the actual export. Current macOS LaunchDaemon configuration also includes periodic dasd activities that require a network connection or an inexpensive network, and the executable uses Apple’s Network framework. Apple has not fully documented whether those internal activities involve direct remote transfer by dasd, which endpoints they might contact, or what they might send. Those details remain unverified.

How much traffic is normal

There is no verified normal range for dasd network traffic. Apple has not published a baseline, and no dependable independent benchmark establishes a particular number of kilobytes, megabytes, or a daily total. Assigning a specific allowance would create certainty that the available evidence does not support.

Based on the documented architecture, dasd should generally spend more of its time coordinating schedules and network conditions than carrying the main data payload. Backups, synchronization, content downloads, and software updates can be much larger, but their principal traffic usually appears under the client app, cloudd, or another transfer service.

That does not prove that dasd always transfers zero bytes. If it is recorded moving a large amount of data for an extended period, the process name alone is not enough to identify either the content or the cause. The activity identifier and the submitting client provide more useful leads.

Can you turn it off

The practical recommendation is to keep dasd running. Apple does not provide a supported system setting or a dedicated switch for turning it off.

Force-quitting the process, blocking it, or modifying its LaunchDaemon may delay or prevent work that relies on the shared scheduler. Possible effects include failed or postponed system maintenance, content refreshes, CloudKit exports, backups, and update activities. The exact set of affected tasks varies with the installed apps and the macOS release, and Apple does not publish a complete client list.

A manual kill may also be temporary because launchd can start dasd again. System protection may prevent other attempted modifications. If dasd appears to cause unusual CPU use, disk activity, wake events, or network traffic, first inspect the activity identifier to find the actual submitting client. Updating or restarting macOS is also safer than dismantling the scheduler.

What people get wrong

• “dasd means Desktop and Search Daemon.” It does not. Apple’s historical manual describes it as a daemon for scheduling background activities. Spotlight’s main indexing work belongs to other processes.

• “dasd is Time Machine, iCloud, or Spotlight.” It is none of those services. They can submit or participate in background work, but dasd is the scheduler used by multiple system and app clients.

• “If dasd appears in a wake record, it performed all the listed work and generated all the traffic.” A record commonly means that dasd arranged execution or a wake on behalf of a client with its own activity identifier. The client may perform the substantial work afterward.

• “dasd itself never transfers any data.” The evidence does not support such an absolute claim. Apple’s CloudKit example attributes the main transfer to the app and cloudd, but current dasd components also include network-conditioned activities and network-related code. Apple has not documented every internal path. What can be said is that dasd is not the main payload process for general background tasks; zero direct transfer cannot be guaranteed.

• “Disabling Login Items or an app’s background activity will disable dasd.” Those settings control background items belonging to the relevant apps. They are not a master switch for the system LaunchDaemon com.apple.dasd, and Apple provides no such dedicated switch.

• “Deleting its plist, repeatedly killing it, or disabling it is a harmless battery-saving tweak.” These actions can disrupt the shared scheduling system. macOS protections may block the change, and launchd may restart the daemon. For abnormal CPU, disk, wake, or network behavior, trace the activity identifier back to its submitter instead.

• “Seeing dasd means the Mac is infected.” An instance at /usr/libexec/dasd with code identifier com.apple.dasd is an Apple system component. A same-named executable found elsewhere should not automatically receive that trust; verify its signature and origin separately.

Seeing what it actually used

If the concern is data usage, first measure the traffic attributed to each process and compare dasd with the client apps and transfer services active during the same period. Bytetally’s per-process history can provide that view without assuming that every task triggered by dasd belongs to dasd itself. Use the timing and activity identifiers together to narrow down which submitted task was responsible.

Related processes

Common questions