A Stop Job Is Running for User Manager for UID 1000: The Real Cause

You type reboot, the desktop disappears, and the screen goes to a black console with a single line on it:

A stop job is running for User Manager for UID 1000 (1min 22s / 1min 30s)

The counter creeps up one second at a time. At 1min 30s the machine finally goes down. You reboot again the next day and it happens again. Somebody on a forum tells you to disable lingering. Somebody else tells you to set DefaultTimeoutStopSec=5s. A third person says it is a GNOME bug. All three "fixes" get upvoted, and all three people are describing a different machine.

Here is the thesis: that message is not vague and it is not a bug. systemd is telling you precisely what is wrong. Something you started under your login is refusing to exit, and systemd is being polite about it for 90 seconds before it stops being polite. Setting the timeout to 5 seconds does not fix that. It just makes systemd reach for SIGKILL sooner, which on a laptop is harmless and on a server is how you end up with a half-written file.

The exact message: "A stop job is running for User Manager for UID 1000"

The wording varies slightly by systemd version and by whether you are on a console or a graphical splash, but it is always one of these:

A stop job is running for User Manager for UID 1000 (10s / 1min 30s)
A stop job is running for User Manager for UID 1000 (1min 29s / 1min 30s)
[  *** ] A stop job is running for User Manager for UID 1000

The two numbers are elapsed time and the deadline. The deadline is TimeoutStopSec for that unit, which by default inherits DefaultTimeoutStopSec from /etc/systemd/system.conf, and the shipped default is 90 seconds. That is the entire reason people see "1min 30s" and not some other number. It is not a magic constant tied to your hardware.

What user@1000.service actually is

Every logged-in user on a modern systemd system gets their own systemd instance. UID 1000 is the first non-system account created at install time, which on a single-user laptop is you. That instance is a system unit called user@1000.service, and it lives inside a slice called user-1000.slice, alongside a scope for each login session.

Two different things can start it:

• A PAM session. When you log in, pam_systemd tells systemd-logind that a session opened. logind starts user@1000.service and a session scope. When your last session closes, logind stops it again.
• Lingering. If loginctl enable-linger has been run for that user, user@1000.service starts at boot and stays up until shutdown regardless of whether anyone is logged in. This is what makes systemctl --user services survive logout, and it is what tools like rootless Podman, Syncthing and a lot of self-hosting guides quietly turn on.

This is the distinction that makes every forum thread contradict every other forum thread. On a machine without lingering, the user manager is stopped when you log out, which usually happens while the display manager is still alive and nobody is staring at a black console counting seconds. On a machine with lingering, the same stop job runs at shutdown, in full view, with a timer on it.

What happens during those 90 seconds

The sequence is worth understanding, because it tells you exactly which knob is the right one.

Finding the unit that is actually hanging

Step 1: make the last boot's journal readable

You cannot read the log of a shutdown that has already happened unless the journal is persistent. On most desktop distributions it already is; on minimal server images it is not.

journalctl --list-boots | tail -n 3

If you only see boot 0, the journal is volatile. Fix it once:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Now reboot once (yes, you will sit through the 90 seconds one more time) so there is a previous boot to inspect. If journalctl is not somewhere you spend much time, my journalctl field guide covers the flags that matter.

Step 2: read the tail of the previous shutdown

journalctl -b -1 -o short-precise | tail -n 80

You are looking for the block between Stopping User Manager for UID 1000... and the kill. In a clean shutdown those lines are within a second or two of each other. In a hanging one you get something like:

systemd[1]: Stopping User Manager for UID 1000...
systemd[1652]: Stopped target Main User Target.
systemd[1652]: Stopping Sound Service...
systemd[1]: user@1000.service: State 'stop-sigterm' timed out. Killing.
systemd[1]: user@1000.service: Killing process 1652 (systemd) with signal SIGKILL.

The last unit systemd reports stopping before the timeout line is your prime suspect. It is not always conclusive because user units stop in parallel, but it is the right place to start.

Step 3: list what is running under your user manager right now

systemctl --user list-units --type=service --state=running

Then look at the whole slice, including processes that belong to no unit at all:

systemd-cgls /user.slice/user-1000.slice

That second command is the one people skip, and it is often where the answer is. A tmux server, a stray ssh with a control master, a background rsync, a rootless container runtime: these live in your session scope, not in a unit, and they are exactly the kind of thing that sits there ignoring SIGTERM.

Step 4: rule out an unkillable process

If a process is in uninterruptible sleep, no signal will help. SIGKILL at the 90 second mark will not even work, and you will see the machine hang past the deadline.

ps -eo pid,stat,wchan:28,comm --no-headers | awk '$2 ~ /^D/'

Empty output means no process is stuck in the kernel. Any output, especially with a wchan mentioning NFS, CIFS or FUSE, means the real problem is a network filesystem that went away while a process still had a handle on it. No systemd setting fixes that. Unmount it before shutdown, or mount it with _netdev and correct ordering so the unmount happens before the network goes down.

Step 5: apply a scoped fix, not a global one

Once you know the unit, give that unit a shorter grace period, or fix its shutdown handling. For a user unit:

systemctl --user edit syncthing.service

[Service]
TimeoutStopSec=15s
KillMode=mixed

KillMode=mixed sends SIGTERM to the main process only, then SIGKILL to everything left in the cgroup at the deadline. That is usually what you want for a service that spawns children which do not forward signals. If the unit is one you wrote, the better fix is to make it handle SIGTERM properly in the first place, which is the same discipline covered in writing a systemd unit that actually keeps your app running.

If you genuinely cannot identify one culprit and you need the machine to reboot fast, bound the user manager alone:

sudo systemctl edit user@.service

[Service]
TimeoutStopSec=20s

sudo systemctl daemon-reload

That caps this one unit at 20 seconds and leaves every other system unit on the machine with its full grace period. Compare that with editing DefaultTimeoutStopSec in system.conf, which caps PostgreSQL too.

Verifying the fix

Confirm the override actually landed before you trust it:

systemctl show user@1000.service -p TimeoutStopUSec

TimeoutStopUSec=20s

Then reboot and check the previous boot again:

journalctl -b -1 -o short-precise | grep -i "user@1000"

A fixed shutdown looks like this, with the stop and the stopped line within a second or so of each other and no "timed out" line at all:

systemd[1]: Stopping User Manager for UID 1000...
systemd[1]: user@1000.service: Deactivated successfully.
systemd[1]: Stopped User Manager for UID 1000.

If you still see State 'stop-sigterm' timed out, you shortened the wait but did not fix the cause. Go back to step 3.

What people get wrong

Common advice	What it actually does	Verdict
DefaultTimeoutStopSec=5s in /etc/systemd/system.conf	Shortens the grace period for every system unit including databases and message brokers	Dangerous on a server, lazy on a laptop
loginctl disable-linger $USER	Moves the stop from shutdown to logout. The hang still happens, just out of sight	Only correct if you never wanted lingering
KillUserProcesses=yes in logind.conf	Kills leftover session processes at logout. Genuinely helps stray terminal processes, does nothing for a hung user unit	Useful, but partial
"It is a GNOME bug, add this drop-in"	Fixes one specific unit on one specific desktop. Irrelevant if you are on a headless server	Correct for a minority, copied by everyone
nowatchdog kernel parameter	Unrelated to user session teardown	Cargo cult

The one that annoys me most is the global timeout, because it is the advice that turns a cosmetic 90 second delay into a real risk. If you run anything stateful on that box, you have just told systemd to SIGKILL it 5 seconds into a shutdown. That is not a fix, that is trading a visible inconvenience for an invisible one.

The second most annoying is the framing that this is "cosmetic on a VM". It is not cosmetic if lingering is on and one of your user services is a database or a sync client, because the 90 second wait is that service failing to shut down cleanly. On a cloud VM where the provider force-stops the instance after its own timeout, you can lose the graceful shutdown entirely.

If it is still hanging

1. Turn on debug logging for one reboot. Run sudo systemd-analyze log-level debug, reboot, then journalctl -b -1 -p debug | grep -i user@1000. Set it back with sudo systemd-analyze log-level info afterwards, because debug logging is noisy.
2. Get a shell during shutdown. sudo systemctl enable debug-shell.service gives you a root shell on tty9 that survives into late shutdown. Switch to it while the counter is running and inspect the process list live. Disable it when you are done; it is an unauthenticated root shell.
3. Check for a second user manager. loginctl list-users sometimes shows an extra UID from a display manager, a container or a service account with lingering turned on. The counter says 1000, but the habit of assuming UID 1000 is the only one costs people hours.
4. Test the teardown without rebooting. From a text console or over SSH as root: systemctl stop user@1000.service and time it. You get the same hang in a survivable context, which makes bisecting units far quicker than a reboot cycle.

Work through it in that order and you will find the process. It is always a process. systemd is just the messenger that had to wait for it.