Control Login Availability with systemd-user-sessions

A host that finished booting but still refuses every login almost always has one culprit: a leftover /run/nologin. systemd-user-sessions.service should have removed it. By the end of this guide you can tell whether the machine has opened for ordinary logins, why that file matters, and how to recover a boot where the gate is still closed. The local system used for these examples runs Ubuntu's systemd package version 255.4-1ubuntu8.17. Allow about 10 minutes. You need a shell; only the commands that inspect or change the system service need root.

What the service controls

systemd-user-sessions.service is a small system service, not a login server and not a user-session manager. Its job is to coordinate with pam_nologin:

• On boot, its start action removes /run/nologin, which lets PAM stacks using that module accept ordinary user logins.
• On shutdown, its stop action creates the same file, which tells those login paths to refuse new sessions.

/run is temporary runtime state, so this file is not a permanent account lock and not a replacement for disabling an account. A login service can still fail for unrelated reasons, and an existing session is not necessarily ended just because the file appears. The practical question is whether new logins are currently blocked by this particular gate.

1. Check the gate without changing it

Start with ordinary, read-only checks. These commands do not need root on the example machine:

systemctl status systemd-user-sessions.service --no-pager
stat /run/nologin

A healthy running service normally reports an active, exited oneshot service. If stat says /run/nologin does not exist, the file-based login gate is open. If it prints the file's metadata, its presence is the relevant condition, regardless of who owns it or when it was created.

For a compact check that is easier to paste into a diagnostic script:

if test -e /run/nologin; then
    echo "new user logins are gated by /run/nologin"
else
    echo "no /run/nologin gate is present"
fi

Do not treat systemctl is-enabled as the login decision. On this installation the unit is static, and its boot ordering and dependencies bring it in; the presence of /run/nologin and the service state are the checks that matter.

2. Identify the installed wiring

systemctl show systemd-user-sessions.service \
    -p Type -p RemainAfterExit -p ExecStart -p ExecStop
systemctl cat systemd-user-sessions.service

On systemd 255 this shows Type=oneshot, RemainAfterExit=yes, and the two actions /usr/lib/systemd/systemd-user-sessions start and /usr/lib/systemd/systemd-user-sessions stop. The unit waits until several basic boot prerequisites, including user lookup, networking, remote filesystems and /home, are ordered appropriately. That is why manually running the helper is usually the wrong first response to a boot problem: the unit exists to fit that action into system startup and shutdown.

3. Recover a gate left behind after boot

If the machine has finished booting but new non-root logins report that the system is not accepting logins, first inspect the service and its recent journal:

systemctl status systemd-user-sessions.service --no-pager
journalctl -u systemd-user-sessions.service -b --no-pager

Look for a failed start or a dependency that has not completed; fixing that underlying dependency is preferable. If the host is genuinely ready for logins and the service simply needs its normal start action retried, use an elevated shell:

sudo systemctl start systemd-user-sessions.service
systemctl is-active systemd-user-sessions.service
test ! -e /run/nologin && echo "login gate open"

Expected output is active followed by login gate open. This action removes the runtime marker through the packaged helper. It does not change passwords, PAM configuration or account state.

4. Understand the shutdown action before using it

If an operator deliberately stopped it during controlled maintenance and the host should accept logins again, the undo action is:

sudo systemctl start systemd-user-sessions.service
test ! -e /run/nologin && echo "login gate restored"

Do not remove /run/nologin with rm as a shortcut. That bypasses the service's ordering and makes it harder to explain the machine's state. If the file keeps returning, investigate a shutdown or a service failure with journalctl rather than repeatedly deleting it.

Common traps

• Confusing this with account locking. The marker controls login paths that honour pam_nologin; it does not disable users or revoke existing sessions.
• Checking only service activity. A oneshot service can be recorded as active after it has exited. Check both systemctl status and the marker file when diagnosing a login problem.
• Running the helper with guessed options. The installed helper accepts only the service actions start and stop. It has no useful general-purpose help mode; an unknown verb exits with an error.
• Ignoring boot ordering. A failed /home mount, user lookup or other prerequisite can explain why the service has not opened logins yet.