If you are using a modern Linux distro, you will surely come across the “A stop job is running” message during shut down, and it will pause the shutdown process for up to 90 seconds. Find out why this message appears, and how you can mitigate it.
It’s a Safety Feature, Not a Bug
The very first thing you need to know is that the “A stop job is running” message is a safety feature built into the system, not a bug.
Modern Linux distributions like Ubuntu, Fedora, and Arch use Systemd to manage the boot and shutdown processes. When you click Shut Down, Systemd does not just pull the power plug. It sends a polite signal called SIGTERM to every running service and application. Most applications, after receiving this signal, save their data, close their files, and shut down gracefully.
However, some services need more time to complete their tasks and ignore the signal. That is when you see the warning message. This delay usually happens because certain services, such as network managers, containers, user sessions, or network mounted drives, need extra time to close connections or save data safely.
Many Linux users search for fixes when they see “A Stop Job is Running” message, assuming something is broken. The truth is that Systemd developers built this behavior on purpose. Basically, it is the waiting period, usually 90 seconds, that Systemd gives services to finish their pending tasks. If a service does not finish within the configured timeout, Systemd forcibly terminates it using SIGKILL and continues the shutdown process.
With this graceful shutdown, many applications finish what they are doing, such as closing files, completing database transactions, and unmounting filesystems cleanly. You can still remove the wait and make shutdowns faster, but doing so also increases the risk of losing recent writes or transactions, corrupting databases or journal files, or leaving mounted drives in an unstable state.
Reducing the Default Timeout
The 90 seconds default wait strikes a balance for many Linux users, especially those using older hardware, since it is long enough for most services to finish their cleanup routines. However, for users running modern laptops or desktop systems, 90 seconds can feel excessive.
Whatever the reason, you can tweak the system configuration file and lower the timeout by telling systemd to give unfinished services a specific number of seconds to complete their tasks.
To get started, launch your terminal and use your preferred text editor to edit the system configuration file:
sudo nano /etc/systemd/system.conf
Next, locate the timeout variable. You will see a lot of text, which represents the global settings for your system. Look for a line similar to #DefaultTimeoutStopSec=90s. The hash symbol at the start of the line means it is commented out or disabled. The system is currently using its internal default, which happens to be 90 seconds.
To modify the value, first remove the hash symbol to activate the line, then change 90 seconds to a shorter duration based on your preference.
Warning: Do not set this value to 0. Setting it to 0 creates an infinite timeout, meaning the system will wait forever for the process to stop. That is the opposite of what we want. A mid-range value (20–30s) is a practical compromise for many users.
Once you are done, save and exit the editor. To apply the changes, you usually need to reboot. Since the issue occurs during shutdown, you may see the long wait one last time. After the next boot, the new second limit will take effect.
Note: In some cases, you may need to enable the #DefaultDeviceTimeoutSec=90s too for it to work.
When the Timeout Might Indicate a Problem
In most cases, a stop job timeout is normal behavior. However, it can sometimes point to an underlying issue, especially if the same service delays shutdown repeatedly. A network mount may have become unreachable, a daemon could be misconfigured, or a service might not be responding properly to shutdown signals.
If you notice shutdowns taking minutes instead of seconds, or the same service timing out every time, it’s worth investigating. Occasional delays are usually harmless, but consistent ones suggest that something needs attention.
To identify the service causing the delay, check the logs after rebooting from a slow shutdown:
journalctl -b -1 -e
This command displays logs from the previous boot and jumps to the end. You can scroll up to look for warnings, timeout messages, or services that the system forcibly stopped.
In addition, you can also narrow things down by viewing warning level messages:
journalctl -b -1 -p warning
Another useful check is to run this Systemd analyze command:
systemd-analyze blameAlthough this command focuses on startup times, services that are slow to start often behave similarly during shutdown. Some other common services that tend to trigger stop job messages include:
- Network services
- Remote filesystems such as NFS or SMB
- Database servers
- Container and virtual machine managers
- External drives, and automount units
Network-based mounts are especially prone to delays if the connection is unstable or no longer available. Also, lowering the shutdown timeout can make shutdowns feel faster, but it does not fix the underlying problem. If a service consistently delays shutdown, addressing the root cause produces better long-term results.
Final Thoughts
Linux gives you a high level of control over your system, including how long it waits for stubborn services to shut down. You can also manage background applications and disable unnecessary services to improve both shutdown and boot times.
