How to Fix “A Stop Job Is Running” Slow Shutdown or Reboot in Ubuntu

The message “A stop job is running for…” accompanied by an agonizing 90-second or 2-minute countdown timer during Ubuntu system shutdown or reboot occurs when systemd issues a termination signal (SIGTERM) to a background service or daemon that fails to exit cleanly. Because systemd is designed to prevent data corruption by allowing processes to finish writing state to disk, it enforces a default watchdog timeout before forcibly killing the stubborn process with SIGKILL. Resolving this issue involves diagnosing which unit is stalling, reducing systemd stop timeouts, and fixing misbehaving background services.

Why systemd Holds Shutdown on Stop Jobs

During the system halt sequence, systemd reverses its dependency tree, terminating user sessions, network daemons, and storage mounts in an orderly cascade. When a daemon receives SIGTERM, it is expected to close file descriptors, commit pending database transactions, and terminate its process ID within a few seconds.

Common scenarios causing prolonged stop jobs include:

• Unresponsive Network Mounts: NFS, SMB, or SSHFS filesystems failing to unmount because the underlying network interface was deconfigured prematurely.
• Hanging User Session Daemons: Web browsers, remote desktop servers (XRDP), or virtual machines holding process locks. For related service failures, see our guide on fixing job for service failed because the control process exited with error code in Ubuntu.
• Database and Container Engines: MySQL, PostgreSQL, Docker, or containerd waiting for stubborn containerised workloads to shut down.
• Defective Polkit or Display Manager Units: Display managers like GDM3 or SDDM deadlocking with audio servers (PulseAudio / PipeWire) during logout.

Signal	Standard Action	systemd Watchdog Role
SIGTERM (Signal 15)	Requests orderly, graceful process termination	Sent immediately when shutdown begins
Watchdog Timeout	Waits for daemon to release memory and file locks	Enforces 90s countdown (DefaultTimeoutStopSec)
SIGKILL (Signal 9)	Immediately terminates process without cleanup	Fired automatically when timer reaches zero

Step 1: Identify the Stalling Service in systemd Logs

Rather than guessing which service causes the delay, inspect the system journal from previous boot sessions to see which unit exceeded the stop timer:

1. Open your terminal application by pressing Ctrl + Alt + T.
2. View the shutdown logs of the previous boot session:

journalctl -b -1 -e

3. Scroll upwards through the final log entries. Look for warnings containing phrases like Timed out stopping... or Killing process... with SIGKILL.
4. Note the exact service name (for example, [email protected], snapd.service, or mariadb.service).

Step 2: Reduce systemd Default Stop Timeout Globally

By default, Ubuntu sets the stop job timeout to 90 seconds. For modern desktop and workstation hardware, 10 to 15 seconds is more than sufficient for any healthy service to flush its buffers. Lowering this threshold drastically shortens shutdown delays.

1. In the terminal, open the main systemd configuration file using an editor with root privileges:

sudo nano /etc/systemd/system.conf

2. Search for the following line (it is usually commented out with a #):

#DefaultTimeoutStopSec=90s

3. Uncomment the line by removing the # and change the value to 10s (or 15s):

DefaultTimeoutStopSec=10s

4. Press Ctrl + O followed by Enter to save, then press Ctrl + X to exit.
5. Apply the same reduction to user-level sessions to prevent hanging desktop apps from stalling logout:

sudo nano /etc/systemd/user.conf

6. Uncomment and update DefaultTimeoutStopSec=10s in this file as well. Save and exit.

Step 3: Fix Hanging [email protected] Delays

If the stop job specifically cites [email protected], a user-space daemon (such as the GNOME Keyring, PipeWire audio, or a background browser instance) is refusing to close its session bus.

1. Open the system logind configuration file:

sudo nano /etc/systemd/logind.conf

2. Locate the setting KillUserProcesses:

#KillUserProcesses=no

3. Change it to yes:

KillUserProcesses=yes

This directive ensures that when the graphical user session terminates, systemd immediately sends termination signals to all child processes spawned by that user rather than leaving them dangling.

Step 4: Handle Network File System (NFS/CIFS) Unmount Locks

If your Ubuntu system mounts external network drives (via /etc/fstab or automount), the system network manager may shut down the network interface before the network filesystems have unmounted, creating an indefinite hang.

1. Open /etc/fstab:

sudo nano /etc/fstab

2. Ensure all network shares include the _netdev mount option. For example:

//192.168.1.50/share /mnt/nas cifs credentials=/home/user/.smbcredentials,_netdev,nofail 0 0

The _netdev flag informs systemd that this filesystem requires network access, guaranteeing that the filesystem will be safely unmounted before NetworkManager stops the network hardware.

Step 5: Apply Configuration and Test Shutdown

After adjusting the configuration files, reload the systemd management configuration to activate the new parameters immediately:

sudo systemctl daemon-reload

Reboot your Ubuntu computer using sudo reboot. If a service hangs during the shutdown sequence in the future, systemd will now enforce the 10-second limit and forcefully terminate the offending process, restoring swift, seamless shutdowns.