Stop your systemd unit from hanging forever on shutdown

Technical Briefing | 10/28/2026

You trigger a reboot on a production node, walk away for a coffee, and come back ten minutes later to find the server still sitting at a stop job for your main application. It is a classic move that burns time during maintenance windows. Usually, this happens because the process ignores SIGTERM, and systemd sits there waiting for the default 90-second timeout to expire before finally hitting it with a SIGKILL.

Why the default timeout is actually your enemy

By default, systemd is patient. If your app is written in a language with a garbage collector or just lacks clean signal handling, it might take its sweet time or simply hang indefinitely when asked to quit. You do not need to wait ninety seconds for a service that is clearly deadlocked. Setting a tighter TimeoutStopSec in your unit file forces the issue, saving you from staring at a blinking cursor while your service fails to exit gracefully.

[Service]
TimeoutStopSec=10
KillMode=mixed

• Use KillMode=mixed to send SIGTERM to the main process and SIGKILL to its children.
• Set TimeoutStopSec to 5 or 10 seconds for services that you know handle signals poorly.
• Verify your unit file with systemctl daemon-reload before you ever need to trigger a restart.

If you are debugging a service that refuses to die, run systemctl status on it right when the stop job starts. Often you will see that it is stuck in an uninterruptible sleep or waiting on a hung I/O operation. At that point, waiting the full minute is just theater. Be aggressive with these settings, because a hung service is worse than a hard-killed one.

Next time you are setting up a new service, don’t just rely on the defaults. Drop these values into a systemd override file so you can actually get your box back online after a command like reboot.