When and How to 'killall Finder' on Mac (Plus Other Useful killalls)

Finder gets stuck. The Dock shows the wrong icon for a folder. The menu bar shows the time as 1969. Something on screen is broken in a way that quitting and relaunching the responsible process would fix — but most of these processes don’t have a Quit menu item. They’re meant to always be running.

killall is the small, useful tool for restarting any of them by name. It’s a Unix command that’s been on macOS since the beginning, and the patterns below are worth memorizing.

How killall works

killall ProcessName

That sends the default signal (SIGTERM, signal 15) to every process with that name. The process exits gracefully. Then launchd — which manages all these system processes — sees that something it’s supposed to keep alive has died, and restarts it.

That last bit is the key. For most macOS background processes, you don’t have to do anything to restart them. Just kill, and they come back. (This is why “killall” is a friendly recovery tool, not a destructive one.)

The big ones

Finder

killall Finder

Use when:

• A folder won’t open and shows the spinning rainbow wheel forever.
• File copies are stuck.
• Finder says a volume is “in use” but you’re sure nothing is using it.
• You changed a defaults write for Finder and want it to take effect.

What you keep: open Finder windows reopen automatically (with the same paths) on the relaunch. Selections inside windows don’t persist. Anything dragged-but-not-released gets canceled.

What you lose: in-flight Finder operations like a copy that was 20% done. The copy stops; partial files left on the destination need to be cleaned up by hand.

Dock

killall Dock

Use when:

• Dock icons are showing the wrong thing.
• The Dock is invisible.
• Mission Control is showing stale window snapshots.
• An app is “bouncing” in the Dock forever.
• You changed a defaults write for Dock.

The Dock process also handles Mission Control and Spaces. Sometimes a stuck Spaces transition resolves only after killall Dock.

SystemUIServer

killall SystemUIServer

Use when:

• The menu bar is showing a stale battery percentage / Wi-Fi indicator.
• A Bluetooth menu icon won’t dismiss.
• The clock format is wrong.
• You changed a system-level menu bar setting that didn’t take effect.

SystemUIServer manages most menu bar items on the right side. Killing it is harmless — it relaunches in under a second.

ControlCenter

killall ControlCenter

Use when:

• A Control Center module (display brightness, audio output, focus) won’t open.
• The “Now Playing” tile in Control Center shows nothing or the wrong app.
• A toggle is stuck on or off in the UI.

This is separate from SystemUIServer on modern macOS — Apple split the menu bar’s right side into “always-visible” (SystemUIServer) and “Control Center modules” (ControlCenter).

NotificationCenter

killall NotificationCenter

Use when:

• Notifications stop appearing.
• Clicking the date/time area doesn’t open the notification stack.
• Banner notifications are stuck on screen.

Power users use Sweep tooEven when you know the Terminal commands, Sweep is faster and harder to mess up. Get Sweep free →

bluetoothd

sudo killall bluetoothd

Use when:

• Bluetooth devices won’t connect.
• The Bluetooth menu shows “Disconnected” but the device is on.
• AirPods won’t switch from another device.

Bluetooth is finicky on macOS. If the menu’s “Turn Bluetooth Off, Then On” doesn’t help, killing the daemon is the next step. Needs sudo because it’s a system daemon.

mDNSResponder

sudo killall -HUP mDNSResponder

Use when:

• A .local hostname won’t resolve.
• AirDrop isn’t seeing other Macs.
• Bonjour-discovered services (printers, AirPlay targets) aren’t appearing.
• DNS is misbehaving in general.

The -HUP flag (signal 1, hangup) tells mDNSResponder to reload rather than fully restart, which is gentler. Pair with:

sudo dscacheutil -flushcache

To flush the directory services cache at the same time. The two together handle most “DNS is broken” issues that aren’t your router’s fault.

WindowServer (don’t, usually)

sudo killall WindowServer

The graphics server. Killing it logs you out — every running app dies, you go back to the login screen. There are very few situations where this is worth doing on purpose; it’s effectively a forced log-out.

If you ever do need it (Mission Control completely hung, can’t switch apps, can’t move windows), it’s the nuclear option short of a hard reboot.

The list with use cases

Process	When to restart
Finder	Stuck windows, broken sidebar, defaults change
Dock	Wrong icons, missing Dock, stuck app bounce
SystemUIServer	Menu bar items showing wrong info
ControlCenter	Control Center modules misbehaving
NotificationCenter	Notifications not appearing
bluetoothd	Bluetooth not connecting (sudo)
mDNSResponder	AirDrop, .local resolution (sudo, -HUP)
cfprefsd	defaults write not taking effect
usbd	USB device not enumerating (sudo, on Intel)
coreaudiod	Audio output dropping out (sudo)

The last one — coreaudiod — is genuinely useful. If your audio dies (silence, or the volume slider does nothing) and you’ve already tried plugging headphones in and out:

sudo killall coreaudiod

CoreAudio relaunches and rediscovers all your audio devices. Saves a reboot.

When killall isn’t enough

Sometimes you killall Finder and it comes back broken in the same way it was broken before. That’s a sign the issue isn’t transient — Finder is reading bad data from somewhere. Common culprits:

• A corrupt preferences file. defaults delete com.apple.finder and killall Finder resets it.
• A network volume that’s hung. Finder relaunches, tries to reconnect, hangs again. Unmount the network drive first: diskutil unmount /Volumes/SharedDrive.
• An external drive failing. diskutil eject it.

In each case, the killall was correct — it was just one ingredient in the fix.

The “stuck file” trick

You’re trying to delete a file and Finder says it’s in use. You quit every app you can think of. Still stuck.

lsof | grep /path/to/the/file

That tells you which process has it open. If it’s something easy to identify (a specific app), quit that. If it’s a system process, killall it:

killall QuickLookUIService
killall mdworker_shared

mdworker_shared is the Spotlight indexer. If it’s holding a file open while indexing, killall it (no sudo needed for your own user’s mdworker).

Skip the Terminal stackSweep does the same cleanup with a UI and a preview before anything is removed. Download Sweep free →

Killing all instances of an app

Use the bundle name (which is also the process name in most cases):

killall Slack
killall "Google Chrome"

Apps with spaces in the name need quotes. Some apps have helper processes that share part of the name:

killall "Google Chrome"
killall "Google Chrome Helper"

You may need to kill them all to fully unload Chrome. Or just use:

killall -9 "Google Chrome*"

-9 is SIGKILL (uncatchable), the wildcard matches multiple. This is the “I just want it gone” option. Note: SIGKILL doesn’t give the app a chance to save state, so unsaved Chrome tabs may be lost.

When you don’t know the process name

ps aux | grep -i finder

Lists every running process whose command line contains “finder.” aux flags show all processes for all users. Use that to confirm the exact name before killall.

A nicer view:

ps -A -o pid,user,comm | grep -i finder

Shows just the PID, owner, and command name.

For interactive process inspection, top and htop (Homebrew) work, but for finding “what’s the right name to killall,” ps aux | grep is fastest.

Signals worth knowing

killall accepts the same signals as kill:

killall -TERM Finder         # Default: graceful exit
killall -KILL Finder         # SIGKILL: uncatchable, immediate
killall -HUP mDNSResponder   # Hang up; many daemons treat as "reload config"
killall -USR1 someprocess    # User-defined; some daemons rotate logs on this

For most things, the default (TERM) is right. KILL is for processes that are ignoring TERM. HUP is for daemons that have a “reload” semantic.

What you can’t killall

A few processes resist:

• launchd itself (PID 1) — killing it crashes the OS. Don’t.
• loginwindow — killing it logs you out.
• Anything inside the kernel — there’s no process to kill; reboot if a kext is misbehaving.
• Stuck “uninterruptible sleep” processes (state code D, rare on macOS) — only a reboot helps.

A scripted relaunch

If you find yourself running the same series of killalls regularly (often after a defaults write spree), wrap them:

#!/bin/bash
# ~/bin/relaunchui
echo "Relaunching UI processes..."
for proc in Finder Dock SystemUIServer ControlCenter NotificationCenter; do
  killall "$proc" 2>/dev/null && echo "  $proc: ok"
done

Make it executable, drop it in your PATH, and it’s one command to refresh the entire UI layer.

When a Force Quit is faster

The Force Quit window (Cmd+Option+Esc) lists user-facing apps. For those apps — Safari, Chrome, your editor — Force Quit is friendlier than the Terminal. killall is for daemons and helper processes that don’t appear in that list.

Both ultimately do the same thing (send SIGTERM to a PID), but the GUI is right there. The Terminal is for everything that isn’t.

There’s a GUI for thatSweep wraps the Terminal cleanup in a UI you don’t have to memorize. Try Sweep free →

A note on safety

There’s an old internet warning that “you should never killall on macOS because it works differently from Linux.” The original difference was that on some BSDs, killall killed every process you owned (a literal “kill all”). On macOS, killall works the way Linux’s killall works — it kills processes matching a name. So the warning is dated.

There are still ways to break things — sudo killall launchd, sudo killall WindowServer — but the everyday list above is safe and routinely used by Mac admins, developers, and Apple’s own support docs.