The machine will not shut down: a request is not a power switch

You press shutdown. The task starts, the spinner turns, and three minutes later the machine is still running. Eventually you press stop and it dies instantly, which raises an obvious question: why did the first one not work when the second one clearly can?

They are not two strengths of the same action. They are two entirely different things.

The distinction everything hangs on

Shutdown is a request. The hypervisor asks the guest to shut itself down, the way pressing the power button on a physical machine asks an operating system to close down cleanly. The guest decides what to do with that request.

Stop is a power cut. It removes power from the virtual machine immediately, with no conversation. The documentation warns about it in plain language: stopping may incur data loss, so use it with caution.

Once you hold those apart, a machine that will not shut down stops being mysterious. It is not refusing. Nobody inside heard the request.

Who is supposed to be listening

There are two possible listeners, and a healthy machine has at least one.

The operating system's power button handler. On a Linux guest this is normally present. On a minimal image, a container-like appliance, or a system that has entered an early boot stage or a rescue shell, it may not be.

The guest agent. When it is enabled and actually running, it gives the hypervisor a direct channel inward and the shutdown request goes that way.

If the agent is off and the power button handler is missing or unresponsive, the request goes out and lands nowhere. The hypervisor is not told "no". It is told nothing, which looks exactly the same from outside and is why the task appears to hang rather than fail.

If your machines routinely take too long to shut down, checking whether the agent is actually working is a better first move than shortening timeouts.

Then the timeout, then the force

The waiting is bounded. Per guest, the default shutdown timeout is 180 seconds; when it expires, the machine is stopped forcefully.

A bulk stop of everything on a node has its own budget: it attempts a clean shutdown, waits up to three minutes by default, and then hard stops whatever is still running.

So the honest description of an unattended shutdown is: ask nicely, wait a fixed period, then pull the plug. If your database needs four minutes to flush, the defaults have already decided that it gets three.

Raise the number, do not skip the question

It is tempting to treat the timeout as the setting to tune. For a machine that genuinely needs longer, raising it is correct.

But a machine that never shuts down no matter how long you wait does not have a timeout problem, and giving it ten minutes only means you wait ten minutes before the same forced stop. Find out whether anything is listening first.

When a shutdown task is already stuck

If a shutdown task is sitting there and you need the machine down now, there is an explicit way to stop it and overrule the running shutdown task rather than queueing behind it. That exists precisely because the stuck-task case is common enough to need an answer.

Use it knowing what it is: still a power cut, with the same warning attached.

The case that catches people out: power failure

This is where the whole article stops being academic.

A power failure script that shuts down guests before the batteries run out inherits every property above. It sends requests. Guests that are not listening ignore them. The timeout runs. Then everything still running gets hard stopped, possibly while the battery is already low and possibly all at once.

Two things are worth checking before you rely on such a setup, and both are cheap:

Do the guests actually respond to a shutdown request? Test one, with a stopwatch, on an ordinary afternoon.

Does the total budget fit the battery? Guests shut down in sequence, and the timeouts add up. A row of machines that each take two minutes is not a two minute shutdown.

A power failure plan that has never been rehearsed is a plan that will be rehearsed once, in the dark, under time pressure.

What Atlas does

Atlas does not invent a third kind of shutdown. Asking and cutting power are the two things that exist, and pretending otherwise would be a lie with consequences.

What it does is refuse to blur them. A destructive action says it is destructive before you confirm it, so "stop" never arrives disguised as a slightly firmer "shutdown". That distinction is the whole subject of this article, and a panel that presents the two as neighbouring buttons of equal weight has already lost it.

The daily summary carries the other half: an unplanned restart is reported as a fact. A machine that was force stopped after failing to shut down cleanly looks, the next morning, exactly like a machine that crashed. Both deserve to be noticed.