Fix systemd System Shutdown in Progress Error (2026)

The systemd-shutdown process is blocking your system from shutting down because a critical service or unit is refusing to stop gracefully.

Here are the common culprits and how to fix them:

1. A Stalled Network Manager

Sometimes NetworkManager gets stuck trying to bring down interfaces or reconfigure routes, holding up the entire shutdown sequence.

Diagnosis: Look for messages like A start job is running for NetworkManager... or NetworkManager-wait-online.service in your journalctl -xb output during shutdown. You can also check the status of NetworkManager directly:
```
systemctl status NetworkManager.service
```
If it’s activating or deactivating for an extended period, this is likely your issue.
Fix: You can force-restart NetworkManager if it’s truly stuck, though this isn’t ideal for production systems. For a quick fix during a hang:
```
systemctl restart NetworkManager.service
```
If this doesn’t work, you might need to specifically address why it’s stalling. Often, it’s related to DNS resolution or DHCP lease renewal failures. Check journalctl -u NetworkManager for specific errors. A more robust fix involves configuring NetworkManager to not be a blocker during shutdown. Edit /etc/NetworkManager/conf.d/10-unmanaged-devices.conf (or create it) and ensure it looks like this:
```
[keyfile]
unmanaged-devices=interface-name:eth0;interface-name:wlan0
```
Replace eth0 and wlan0 with your actual interface names. This tells NetworkManager to ignore these devices, preventing it from getting stuck on them.

Another common cause is NetworkManager-wait-online.service. You can disable this service if your system doesn’t strictly need to wait for network connectivity before proceeding with shutdown:
```
systemctl disable NetworkManager-wait-online.service
```
This allows shutdown to continue even if the network isn’t fully up or down.

2. A Frozen systemd-udevd

The device manager udev can sometimes hang if it encounters a problematic device or driver during its shutdown phase, preventing other services from stopping.

Diagnosis: In journalctl -xb, you’ll see systemd-udevd.service taking a long time to stop. You might see A start job is running for udev Kernel Device Manager....
Fix: There’s no direct "restart udev" command that fixes a hang. The problem is usually with a specific device or driver. Check journalctl -u systemd-udevd for errors related to specific devices (e.g., USB devices, storage controllers). If you identify a problematic device, you might need to:
- Unplug it: If it’s an external device (like a USB drive) that’s causing the hang, unplugging it before shutdown can resolve the issue.
- Blacklist the driver: If it’s an internal component, you might need to blacklist its kernel module. For example, to blacklist the usb-storage module, create a file /etc/modprobe.d/blacklist-usb-storage.conf with the content:
```
blacklist usb-storage
```
  Then, rebuild your initramfs (e.g., update-initramfs -u on Debian/Ubuntu, dracut -f on Fedora/CentOS) and reboot.

3. A Non-Responsive Application Service

Many applications run as systemd services. If an application’s stop command hangs indefinitely, it will block shutdown.

Diagnosis: Use journalctl -xb to identify which service unit is taking an unusually long time to stop. Look for lines like A stop job is running for <service-name>.service.
Fix:
- Graceful Restart: First, try restarting the service manually to see if it hangs then:
```
systemctl restart <service-name>.service
```
  If it hangs here, investigate the application logs (e.g., /var/log/myapp.log or journalctl -u <service-name>) for errors during shutdown. The application might be failing to save data, close connections, or release resources.
- Adjust TimeoutStopSec: In the service’s unit file (e.g., /etc/systemd/system/<service-name>.service or /usr/lib/systemd/system/<service-name>.service), you can increase the time systemd waits for the service to stop. The default is often 90 seconds. Edit the unit file and add or modify:
```
[Service]
TimeoutStopSec=300
```
  This gives the service 300 seconds (5 minutes) to stop. After editing, reload systemd and restart the service:
```
systemctl daemon-reload
systemctl restart <service-name>.service
```
- Forceful Stop (Last Resort): If the service consistently hangs and you cannot fix its internal shutdown logic, you can configure systemd to kill it forcefully after a timeout. In the [Service] section of the unit file:
```
[Service]
KillMode=mixed
TimeoutStopSec=30
```
  KillMode=mixed (or process) ensures that systemd sends SIGTERM to the main process and then SIGKILL if it doesn’t exit within TimeoutStopSec. KillMode=process is safer as it only kills the main process, KillMode=control-group kills everything in the cgroup. Use mixed or process with caution as it can lead to data corruption if the application is in the middle of writing.

4. systemd-journald Buffering Issues

If the journal is configured to buffer logs to disk and the disk becomes unavailable or full, journald might hang during shutdown as it tries to flush its buffers.

Diagnosis: Look for systemd-journald.service taking a long time to stop in journalctl -xb. You might see disk I/O errors or "no space left on device" messages related to /var/log/journal.
Fix:
- Check Disk Space: Ensure the partition where /var/log/journal resides has sufficient free space.
```
df -h /var/log/journal
```
  If it’s full, free up space by deleting old logs or resizing the partition.
- Journal Configuration: Examine /etc/systemd/journald.conf. If Storage=auto or Storage=persistent is set and the disk is problematic, journald will try to write. You can temporarily set Storage=volatile to make journald only use RAM, which will prevent it from blocking shutdown due to disk issues.
```
[Journal]
Storage=volatile
```
  Reload systemd after changes:
```
systemctl daemon-reload
```
  This is a workaround; the real fix is to address the underlying disk problem.

5. A Frozen Mount Point

If a filesystem mounted via systemd units (e.g., an NFS mount, a CIFS mount, or even a local filesystem with a faulty fsck check) becomes unresponsive, it can block shutdown.

Diagnosis: Check journalctl -xb for A stop job is running for remote-fs.target or specific mount units (mnt-mydata.mount). You might see umount commands timing out.
Fix:
- Check fstab and systemd Mount Units: Ensure there are no problematic entries in /etc/fstab or corresponding .mount files in /etc/systemd/system/. For network mounts (NFS, CIFS), ensure the server is reachable and the mount options are correct.
- Add nofail Option: For non-critical mounts, especially network ones, add the nofail option to their fstab entry. For example, for an NFS mount:
```
nfsserver:/exports/data /mnt/data nfs defaults,nofail,_netdev 0 0
```
  The nofail option tells systemd not to consider the system failed if the mount cannot be established or unmounted, allowing shutdown to proceed. The _netdev option is also important for network mounts, indicating that they require network access.
- Manual Unmount: If you can identify the specific mount point causing issues, try unmounting it manually before attempting a shutdown.
```
umount -l /mnt/mydata
```
  The -l option performs a lazy unmount, detaching the filesystem from the hierarchy now and cleaning up references later.

6. systemd-logind Waiting for User Sessions

If logind is configured to wait for all user sessions to be terminated, and a session is somehow stuck or unresponsive, it can delay shutdown.

Diagnosis: You might see A stop job is running for Session ... or systemd-logind.service taking a long time.
Fix: This is rare, but can happen if a graphical session crashes and doesn’t properly log out.
- Check Active Sessions:
```
loginctl list-sessions
```
  If you see a session that appears stuck or is not associated with an active user, you can try terminating it:
```
loginctl terminate-session <session-id>
```
- Configure KillUserProcesses: In /etc/systemd/logind.conf, ensure KillUserProcesses=yes is uncommented. This tells logind to kill all processes associated with a user when their session ends, preventing lingering processes from blocking shutdown.
```
[Login]
KillUserProcesses=yes
```
  Reload systemd after changes:
```
systemctl daemon-reload
```

After addressing the specific cause, the next error you might encounter is a timeout during a different service’s shutdown, or potentially an unclean shutdown if the fix involved forceful termination.

More Deep Dives in Systemd