A Mac that will not shut down is almost always waiting for something rather than broken. macOS asks every running app to quit, and it will wait indefinitely for one that says no — or that has stopped answering at all. The trick is finding which one before reaching for the power button.
The commands below were run on macOS 26.5.2 and none of them shut anything down.
Which kind of “won’t shut down”
Three different situations get described the same way, and they have nothing in common except the wording:
- Nothing happens when you choose Shut Down. An app is blocking it, usually with a dialog hidden behind other windows.
- The screen goes to the spinner and stays there. Something has stopped responding rather than refusing politely.
- It shuts down and comes back on by itself. Not a shutdown problem at all — see the last section.
The first is by far the most common, and it has a fix that takes seconds once you know where to look.
The app that refuses to quit
An app with unsaved changes will put up a “do you want to save?” dialog and cancel the shutdown while it waits for an answer. If that window is behind a full-screen app, or on a display that is switched off, the Mac looks like it is ignoring you.
Command-Tab through the running apps before anything else. The one holding the dialog is usually obvious the moment you get to it, and answering the prompt lets the shutdown continue on its own.
When nothing is visibly asking, look for an app that has stopped responding. The process state tells you directly:
$ ps -Ao pid,stat,comm | grep -v ' S\| I' | headA process in state U is in uninterruptible wait — blocked on I/O that is not coming back, typically a network share or a disk that went away. Those cannot process the quit request macOS sent them, which is exactly why the shutdown never proceeds. The same diagnosis applies when Finder itself stops responding, and sample <pid> works the same way here for seeing where a stuck app is parked.
Quitting that one app with killall or the Force Quit window is usually enough to let the shutdown finish normally, and it is a great deal gentler than cutting power to the whole machine.
What pmset assertions do and do not cover
This command comes up in every thread on the subject, so it is worth being precise about what it answers:
$ pmset -g assertions
Assertion status system-wide:
UserIsActive 1
PreventUserIdleDisplaySleep 0
PreventSystemSleep 0
PreventUserIdleSystemSleep 1
Listed by owning process:
pid 43676(caffeinate): [0x0016f5c800018411] 00:00:31 PreventUserIdleSystemSleep named: "caffeinate command-line tool"
Details: caffeinate asserting for 300 secs
Localized=THE CAFFEINATE TOOL IS PREVENTING SLEEP.
Timeout will fire in 269 secs Action=TimeoutActionRelease
pid 534(powerd): [0x00160f3200018b75] 16:24:21 PreventUserIdleSystemSleep named: "Powerd - Prevent sleep while display is on"Lines selected from a longer report; one entry naming an attached input device was removed. Every assertion is attributed to a PID with a human-readable reason, which makes this the definitive answer to “why will this Mac not sleep”.
The honest caveat: these are sleep assertions, not shutdown blocks. A process holding PreventUserIdleSystemSleep is not what is stopping your shutdown. It is still worth running, for two reasons — it identifies background tools you forgot were running, and it is the right command when the actual complaint is a Mac that never sleeps or wakes up on its own.
In the output above, a caffeinate process was deliberately holding sleep off, with a timeout that would release it. That is a tool doing its job; a decade-old copy of one left running by a since-uninstalled app is the version worth finding.
Forcing it, in the right order
If a specific app is stuck and you can still use the machine, force quitting that app is the least destructive step. Option-Command-Esc opens the Force Quit window; the process view above tells you which name to pick.
The documented last resort is holding the power button for about ten seconds, which cuts power. That is not a shutdown — file system writes in flight are lost, and any app that had not saved gets no chance to. Use it after the softer options, not instead of them.
The middle option people forget is sudo shutdown -h now from Terminal, which asks the system to shut down at a lower level than the menu item does. It still allows apps to be terminated in order, so it is a genuinely gentler step than the power button and often gets past a stuck menu-driven shutdown.
It shuts down, then turns itself back on
This is a different problem with a different cause, and two settings explain most of it.
The first is scheduled startup — pmset -g sched lists any wake or power-on schedule, which is easy to have set years ago and forgotten. The second lives in NVRAM: auto-boot controls whether the Mac powers on when it receives power, which is why some machines start the moment you plug the charger in. Reading it is covered in the NVRAM guide, along with why deleting one variable beats resetting everything.
If neither applies, look at what is connected. A keyboard or mouse that sends an event as the Mac powers down can wake it straight back up, and a dock or hub delivering power can trigger the same thing. Disconnecting everything and shutting down once is the quickest way to find out — the same first move as when a Mac hangs at startup, and for the same reason.