My Mac registers 533 background jobs. Only 262 of them are running.

Open Activity Monitor on a Mac that is doing nothing and the list is long enough that most people stop reading it. The usual response is to assume something is wrong, or that the machine is cluttered, and to go looking for things to switch off.

This is a census instead. Every launchd job registered on one MacBook Pro, counted, split by whether it is actually running, and tabulated by how it last ended.

533

What launchd is counting

launchd is the process that starts and supervises almost everything on macOS. It is process 1, it starts at boot, and it does not exit until the machine does. Everything else descends from it.

The important thing for this article is that launchd does not simply start a list of programs and leave them running. It holds a table of jobs. A job is a description: this is the label, this is the executable, and this is what should cause it to run. Some jobs are told to run immediately and stay running. Most are told to wait for something.

launchctl list prints that table.

launchctl list | head -5

PID	Status	Label
684	0	com.apple.Finder
57935	0	application.com.logi.pluginservice.71590053.71590058
-	0	com.apple.SafariHistoryServiceAgent
-	-9	com.apple.knowledgeconstructiond

Three columns. The PID is the process ID if the job is currently running, and a dash if it is not. The status is how it last ended. The label identifies it.

The census

launchctl list | tail -n +2 | wc -l
launchctl list | awk 'NR>1 && $1!="-"' | wc -l
launchctl list | awk 'NR>1 && $1=="-"' | wc -l

Run six times in succession, the counts did not move:

Category	Count
Registered jobs	533
With a live PID	262
Dormant, no process	271

Slightly more than half of everything registered on this machine is not running. It has a table entry and nothing else.

The stability of those six samples is misleading on its own, and it is worth saying so before going further. Earlier in the same session, on the same machine with nothing deliberately started or stopped, the same command returned 532 and then 528. The total is steady second to second and drifts over minutes.

The reason is visible in the labels. Fourteen of the 533 entries begin with application., and those are per-application registrations created when a program launches and withdrawn when it quits:

application.com.google.Chrome.357382.73663713
application.com.logi.pluginservice.71590053.71590058
application.cc.ffitch.shottr.26912081.26912090

So the number is a snapshot of what was open, not a constant belonging to the operating system. Any figure of this kind published without the surrounding conditions is close to meaningless, which is why the conditions are printed at the top of this page.

271

That is the design working as intended rather than a sign of neglect. A job like com.apple.quicklook has no reason to occupy memory until something asks for a preview. The registration is what allows it to appear the instant it is needed, and the dash in the PID column is what it costs in the meantime.

Here is a sample of what was sitting dormant:

com.apple.SafariHistoryServiceAgent
com.apple.quicklook
com.apple.parentalcontrols.check
com.apple.knowledgeconstructiond
com.apple.AssetCache.agent
com.apple.devicecheckd
com.apple.diagnosticextensionsd

Each of these has a trigger. Some wait on a connection to a named service. Some wait on a file appearing in a particular directory, some on a calendar interval, some on a hardware event. Until that happens, none of them is a program in memory.

Who owns the 533

launchctl list | awk 'NR>1{print $3}' | awk '/^com\.apple/{a++} !/^com\.apple/{o++} END{print a, o}'

Owner	Jobs
com.apple.*	509
Everything else	24

Ninety-five percent of the registered jobs are Apple’s own. The twenty-four that are not came from installed software: an SSH agent, a Microsoft updater, a Logitech daemon, and the fourteen per-application entries described above.

This ratio is worth holding onto, because the folk remedy for a slow Mac is to hunt for third-party background processes. On this machine there were twenty-four of them to find, against 509 belonging to the operating system, and fourteen of the twenty-four would disappear on their own simply by quitting the app that registered them.

The exit statuses, which look worse than they are

The status column is the part most likely to alarm someone reading it for the first time.

launchctl list | awk 'NR>1{print $2}' | sort | uniq -c | sort -rn

Last exit status	Jobs
0	327
-9	202
78	2
1	2

A positive status is an ordinary exit code. A negative status means the job was terminated by a signal, and the number is the signal. So 202 jobs on this machine last ended because something sent them SIGKILL.

202

SIGKILL cannot be caught, blocked or ignored. A process receiving it stops immediately without cleanup. Read in isolation that sounds like two hundred crashes.

It is not, and the reason is the on-demand model again. When a job has finished the work it was woken for, it is supposed to exit on its own. Many do, which is where a large part of the 318 clean exits comes from. Others are still holding resources, still inside a run loop, or simply slower to notice that they are finished. Rather than leave them resident, launchd stops them. For a job whose entire purpose was to handle one request and disappear, being stopped is the normal end of the cycle, not a failure.

Genuine crashes tend to look different. A segmentation fault arrives as signal 11, an abort as signal 6. Neither appeared on this machine at all. What appeared was one signal, repeated two hundred times, which is a pattern rather than a fault.

To check that reading rather than assume it, the same table was searched for the signals a real fault produces. Segmentation faults arrive as signal 11 and aborts as signal 6:

launchctl list | awk 'NR>1 && ($2=="-11" || $2=="-6")' | wc -l

0

Not one job on this machine had ended either way. Two hundred and two SIGKILLs and zero fault signals is the signature of a mechanism doing its job, not of software falling over.

The four that are worth looking at

Which leaves the small residue. Four jobs reported a positive exit status, meaning they ended on their own terms rather than being killed:

launchctl list | awk 'NR>1 && $2>0'

79253	1	com.apple.Siri.agent
23726	1	com.apple.Dock.agent
-	78	com.logitech.manager.daemon
-	78	com.openai.atlas.update-helper

The first two are running right now, with live PIDs. A status of 1 next to a live process means the job exited non-zero at some point and launchd started it again, which is the supervision half of its role and needs no attention.

The two that matter are the ones underneath.

Status 78 is EX_CONFIG, the conventional exit code for a program that started, read its configuration, found it unusable and gave up. It is one of the few entries in the whole table that describes something actually broken.

Both of them are third-party. Neither is Apple’s. That is the census arriving at the same conclusion from the other direction: 509 Apple jobs produced no configuration failures at all, and the two that failed came from installed software, out of a third-party population of twenty-four.

Neither is doing any harm. A job that exits immediately on a bad configuration consumes almost nothing, which is why both had gone unnoticed. But if the goal is to find something genuinely wrong on a Mac, this line of the table is where it is, and it takes one command to read.

Why the process count is larger

At the same moment the job census was taken, the machine was running considerably more processes than launchd held live jobs.

ps -A | tail -n +2 | wc -l
ps -M -A | tail -n +2 | wc -l

Measure	Count
Processes	687
Threads	4,394
launchd jobs with a PID	262

Sampled three times back to back, the process count did not move and the thread count varied by one.

4,394

The gap between 687 and 262 is not a discrepancy. launchd starting a job does not prevent that job from starting processes of its own, and applications launched from the Dock are not launchd jobs in the first place. Of the 687 processes, 550 were running from system paths.

The busiest of those, by thread count, were unglamorous:

Process	Threads
WindowServer	23
fseventsd	20
PerfPowerService	13
bluetoothd	12
airportd	11
coreaudiod	11

Drawing the screen, watching the file system, managing power, and running the radios. This is the floor beneath any Mac that is switched on, and it is not optional in any useful sense.

What this means if you were about to disable something

The instinct that produces a slow afternoon of switching things off runs into the census directly.

The 269 dormant jobs are consuming no CPU and no resident memory, so disabling them reclaims nothing. What it does do is remove the trigger that would have started them, which means the feature stops working at the moment it is next needed, usually without an obvious explanation connecting the two.

The 262 running jobs are a different question, but the list above is what most of them are. Removing the window server, the file system event daemon or the audio daemon is not a tuning exercise.

That leaves the twenty-five third-party entries, which is where the genuine candidates live: updaters that check hourly, sync agents for services no longer used, helper daemons left by uninstalled software. Twenty-five is a small enough number to read individually, and reading them is a better use of an afternoon than disabling anything Apple registered.

Reproducing this

Every figure above comes from three commands, none of which need sudo and none of which change anything:

# the census
launchctl list | tail -n +2 | wc -l
launchctl list | awk 'NR>1 && $1=="-"' | wc -l

# ownership split
launchctl list | awk 'NR>1{print $3}' | grep -c "^com.apple"

# exit statuses
launchctl list | awk 'NR>1{print $2}' | sort | uniq -c | sort -rn

Your totals will differ. The count depends on what is installed, what is currently open, and which macOS version you are on, and the numbers here describe one machine on one build rather than a target to match. What should hold is the shape: a large registered total, roughly half of it dormant, an overwhelming Apple majority, and a substantial block of SIGKILL exits that are not crashes.