killall Dock on Mac: Lowercase dock Matches Nothing

I typed killall dock on the Mac mini that runs this business and got No matching processes belonging to you were found, exit code 1. The Dock was running the whole time, as PID 922, started at boot nine days earlier. killall Dock with a capital D found it on the first try. That one letter explains a lot of the searches I pulled today: "killall dock not working" returned 13 Google autocomplete completions in our own collection and "killall dock no matching processes" returned 9.

Case is only the first of five ways killall picks a different set of processes than you expect. Below is what killall Dock actually does, how long the Dock takes to come back and why it comes back at all, and the name rules I confirmed against Apple's killall source and about 40 probes on macOS 26.4.1. I also went through every Stack Exchange question with killall in the title to see which of these problems people actually hit.

What killall Dock does

It sends SIGTERM to every process you own whose name is exactly Dock. That's all killall does. The restart isn't killall's doing. launchd, the macOS service manager, starts a new Dock because the Dock's launch agent tells it to. Here is /System/Library/LaunchAgents/com.apple.Dock.plist on this machine, converted to JSON:

$ plutil -convert json -o - /System/Library/LaunchAgents/com.apple.Dock.plist
  "KeepAlive": {"AfterInitialDemand": true, "SuccessfulExit": false},
  "ThrottleInterval": 1,
  "POSIXSpawnType": "App"

SuccessfulExit: false means "restart it if it didn't exit cleanly". When I killed it, the Dock didn't exactly die from the signal. It caught SIGTERM and exited with code 1, which launchd counts as a failure. launchctl print gui/501/com.apple.Dock.agent afterwards showed runs = 2 and last exit code = 1.

So is killall Dock safe? For the Dock process itself, yes. It holds no unsaved work, and the new copy reads its preferences again on launch, which is why every defaults write com.apple.dock ... tip ends with it. The one thing I saw beyond the Dock was its helper com.apple.dock.extra getting a new PID too (1056, then 44370). Community reports in the census below describe badges missing and windows rearranging afterwards, and one Dock that never came back. I didn't see those, but this Mac mini runs headless, so I had no screen to check them on.

How fast the Dock and Finder come back

I timed it with a small Python script that records the old PID, runs killall, and checks pgrep -x -U 501 every 20 ms until a new PID appears:

Command	launchd label	KeepAlive	New PID after	launchd recorded
killall Dock	com.apple.Dock.agent	SuccessfulExit false	0.162 s	exit code 1
killall -KILL Dock	com.apple.Dock.agent	SuccessfulExit false	0.188 s	not captured
killall -HUP Dock	com.apple.Dock.agent	SuccessfulExit false	0.171 s	Hangup: 1
killall Finder	com.apple.Finder	SuccessfulExit false	0.094 s	Terminated: 15
killall SystemUIServer	com.apple.SystemUIServer.agent	SuccessfulExit false	0.133 s	Terminated: 15
killall ControlCenter	com.apple.controlcenter	SuccessfulExit false	0.098 s	Terminated: 15
killall NotificationCenter	com.apple.notificationcenterui.agent	true	0.156 s	Terminated: 15

All seven came back in under 0.2 seconds. Only the Dock caught SIGTERM and exited with code 1; the others died from the signal itself, which launchctl print shows as last terminating signal rather than an exit code. I read what those fields mean in launchctl print last exit status. One I didn't kill: bird, the iCloud Drive daemon, which shows up in "mac killall bird" searches. Its plist has no KeepAlive key at all, so it runs on demand and the next request is what starts it again.

Why killall dock says no matching processes

Apple's killall is the FreeBSD one, built from the shell_cmds project. what /usr/bin/killall prints shell_cmds-329, which is also the newest tag of Apple's published source. Five rules from that file explain every "no matching processes" I could produce.

1. The match is exact and case-sensitive

Line 533 is strcmp(thiscmd, av[j]) == 0. No prefix matching, no case folding. Every name below came back with "No matching processes" and exit 1 on this machine with killall -s, the dry-run flag:

$ killall -s Dock
kill -term 922
$ killall -s dock        # lowercase
No matching processes belonging to you were found
$ killall -s Dock.app    # bundle name
No matching processes belonging to you were found
$ killall -s finder
No matching processes belonging to you were found
$ killall -s "Control Center"   # the real name is ControlCenter
No matching processes belonging to you were found

macOS's default file system ignores case, so ls -d /System/Library/CoreServices/dock.app works in lowercase. killall compares strings in memory, and that string has a capital D. If you want case-insensitive matching, use pkill -ix dock: pgrep -ix dock found PID 922 where pgrep -x dock found nothing.

2. It only sees your own processes

For anyone but root, line 336 asks the kernel only for processes whose real user ID is yours. That's where the "belonging to you" in the message comes from. Line 586 drops those words when you're root. coreaudiod runs as _coreaudiod, mDNSResponder as _mdnsresponder and WindowServer as _windowserver, so killall coreaudiod without sudo gets the same message as a typo. cfprefsd is the odd one: 14 copies were running here, one per account, and killall -s cfprefsd picked 1 of them, mine.

3. The name is argv[0], not the app name

killall reads each process's argument area through KERN_PROCARGS2 (line 414), skips the executable path, and takes argv[0]. For the 45 distinct apps running on this Mac, the executable name matched the bundle name every time, but 8 of them contain spaces (Google Chrome Helper (Renderer)), so they only match quoted in full. The name in Activity Monitor can still be different from either one. The VS Code question, with 61,908 views, tried killall "Visual Studio Code" and killall "Code"; the accepted answer used Electron, the name of the executable at the time.

argv[0] is also whatever the process says it is. I started sleep with exec -a fakename: killall -s fakename found it, and killall -s sleep didn't.

4. Everything up to the last slash is thrown away

Lines 446 to 449 strip any path from argv[0], so a process started as /usr/bin/foo matches foo. They don't check that it's a path. A Node process that set process.title = 'worker [3000/idle]' is visible to killall only as idle]:

$ killall -s 'worker [3000/idle]'
No matching processes belonging to you were found
$ killall -s 'idle]'
kill -term 48472

This is the unsolved part of a Stack Overflow question about mongrel_rails: five processes visible in ps, and killall said none were running. Their titles looked like mongrel_rails [3003/1/0]: handling 127.0.0.1: GET /music_service_admin. I started a process with that exact argv[0]. killall mongrel_rails found nothing and killall music_service_admin found it. The only answer there suggests pkill -f, which matches the whole command line and works, but nobody explained why killall fails.

5. -m is an unanchored regex

killall -m dock didn't select the Dock. It selected com.apple.dock.extra and com.apple.dock.external.extra.arm64, because lowercase "dock" appears inside those names and not in Dock. A pattern of very, meant for a test process, also caught AMPDeviceDiscoveryAgent ("Discovery"). The man page warns that a single dot matches every process you own. Patterns are POSIX extended regex, so (?i)dock is rejected as an illegal regexp. Anchor with ^...$ and look at -s output before you drop it.

Dry-run first: killall -s

The flag I use most is -s. It prints the kill commands it would run and exits 0 without sending anything. That mattered more than I expected: killall -s node listed 9 PIDs on this machine. One was my test server. The other 8 were MCP bridge servers from a Claude Code plugin, one per agent session, the oldest started 9 days ago and one belonging to the session I was typing in. "killall node" is a common fix for a stuck dev server, and on this machine it would have killed my own agent's tooling with it. For killing a server by its port instead of its name, see kill port on Mac.

Exit codes are worth knowing if you script it. killall returns 0 if it matched anything, even with -s, and 1 if it matched nothing. A second killall against a process that's already gone returns 1, and -q hides the message but keeps the 1. In a script that runs under set -e, write killall -q Dock || true.

What 41 macOS killall questions are about

I pulled every question with "killall" in the title from Ask Different (18), Super User (15) and Stack Overflow (70) through the Stack Exchange API: 103 questions, 41 of them about macOS. I sorted the 41 by title:

• Something broke after the kill (9 questions, 155,122 views). The biggest is sudo killall coreaudiod leaving no sound at 129,870 views; its top answer restarts the daemon with sudo launchctl stop and start instead. Another is a Dock that didn't come back, fixed by deleting ~/Library/Application Support/Dock/desktoppicture.db.
• Name or owner mismatch (6, 127,220 views). Rules 1 to 4 above: a lighttpd that killall couldn't see (44,812 views), Finder after a force quit, VS Code, mongrel_rails, and a "Logi Options Daemon" whose real name was LogiMgrDaemon.
• Applying settings without a kill (9, 31,628). Mostly "I ran defaults write, can I avoid killall Dock".
• Signal meaning (5, 44,831). Is killall a quit or a force quit? It's SIGTERM, which an app can catch, as the Dock does.
• Calling killall from app code (6, 15,448), mostly sandbox "Operation not permitted", and other (6, 30,038).

The name problems have fewer views than the after-effects, but they're the ones nobody fully answered: the mongrel_rails thread has no accepted answer, and the lighttpd thread's accepted answer is "try sudo".

If a killed agent doesn't come back

When the process belongs to a launchd job, restart it through launchd instead of killing it. launchctl kickstart -k gui/$(id -u)/com.apple.Dock.agent stops the job and starts it again; here it returned 0 and the Dock went from PID 45323 to 52458. For the Dock, the label is com.apple.Dock.agent; launchctl list | grep -i dock shows it with its current PID. The same applies to the long-running jobs I run myself. A job with KeepAlive will come back under a new PID after you kill it, which is the difference between the agents and daemons in LaunchAgent vs LaunchDaemon.

FAQ

Why does killall dock say no matching processes?

macOS killall compares names exactly and case-sensitively, and the Dock's process name is Dock with a capital D. killall dock, killall DOCK and killall Dock.app all fail with "No matching processes belonging to you were found" and exit code 1. Use killall Dock, or pkill -ix dock if you want case-insensitive matching.

Is killall Dock safe?

Yes, for the Dock itself. killall Dock sends SIGTERM, and launchd starts a new Dock right away because its launch agent sets KeepAlive with SuccessfulExit false. On macOS 26.4.1 the new Dock appeared 0.16 seconds later. Some users report missing badges or rearranged windows afterwards, and in rare cases a Dock that doesn't return; launchctl kickstart -k gui/$(id -u)/com.apple.Dock.agent starts it again.

What does killall Dock do?

It sends the TERM signal to every process you own named exactly Dock. The Dock quits, and launchd immediately starts a fresh copy that rereads its preferences, which is why tips that change Dock settings with defaults write end with killall Dock. killall itself doesn't restart anything; the restart comes from launchd.

Method: every command ran on 2026-10-07 between 13:31 and 13:45 KST on a Mac mini M4 (Mac16,10, macOS 26.4.1 build 25E253) as user 501 without sudo, in a logged-in Aqua session on a machine with no display attached. killall is shell_cmds-329; line numbers refer to that tag's killall.c on GitHub. Respawn times come from one run each, polled every 20 ms, so treat them as "under 0.2 s", not as benchmarks. The renamed processes were /bin/sleep started with zsh's exec -a and a Node v26.8.1 process setting process.title. I didn't test sudo, and I couldn't see visual side effects of restarting the Dock on a headless machine. The 41-question census is every Ask Different, Super User and Stack Overflow question with killall in the title as of today, sorted into buckets by title. The autocomplete counts are from our own Google suggest collection on the same day.