Inspect and Restart systemd-logind Safely

Restarting systemd-logind blind on the only SSH session to a box is how people lock themselves out. This guide gets you checking it, understanding what it manages, and restarting it only for a clear reason. The examples match systemd 255.4-1ubuntu8.17 installed on this machine.

Allow about fifteen minutes. You need a shell and a working systemd host. The inspection commands are normally unprivileged. Restarting the service needs elevated privileges and can affect login, seat, device and power-management operations, so do it from a maintenance window or a second connection rather than an only SSH session.

1. Check the service before touching it

Start with a read-only status check. Use the full unit name so the command is unambiguous:

$ systemctl status systemd-logind.service --no-pager --full
● systemd-logind.service - User Login Management
     Loaded: loaded (.../systemd-logind.service; static)
     Active: active (running) ...

The timestamps, process ID and drop-in list will differ. The useful facts are Loaded and Active. This service is normally static, not enabled in the usual boot-target sense. Do not try to fix a static result with systemctl enable; static means the unit starts through its dependencies or activation paths.

For a script or a short diagnostic, avoid parsing the decorative status output:

$ systemctl is-active systemd-logind.service
active
$ systemctl show systemd-logind.service -p LoadState -p ActiveState -p SubState -p MainPID --no-pager
MainPID=944
LoadState=loaded
ActiveState=active
SubState=running

Checkpoint: if is-active does not print active, stop here and collect the failure details before restarting anything.

2. See what logind is responsible for

Use loginctl to inspect those objects:

$ loginctl list-sessions --no-legend
1 1000 alice - - closing no -
$ loginctl list-users --no-legend
1000 alice no closing
$ loginctl list-seats --no-legend
seat0

These rows are host-specific. A session ID is the first column of list-sessions; do not assume it is your Unix user ID. The state may briefly show a session closing, especially right after a connection ends.

3. Inspect one session in detail

Replace SESSION_ID with the first column from your own session list. The human-readable view is useful when investigating a login that is still present:

$ loginctl session-status SESSION_ID --no-pager
SESSION_ID - USER (UID)
  Since: ...
  State: ...
 Leader: ...
 Service: sshd
   Type: tty
  Class: user
   Unit: session-SESSION_ID.scope

Do not treat the example values as defaults. A graphical session may show a different service and type, and the leader and process list change over time. For automation, ask for named properties instead of scraping the formatted status:

$ loginctl show-session SESSION_ID \
    -p Id -p User -p Name -p Remote -p Service -p Type -p Class \
    -p State -p Leader -p Scope -p IdleHint --value

The --value form prints values in the order requested. If the session disappears between the two commands, that is a race in a changing system, not proof that logind is broken. Re-run list-sessions and use a current ID.

4. Check configuration without editing it

Behavioural settings belong to logind.conf, with local drop-ins under /etc/systemd/logind.conf.d/. Vendor and runtime directories can also contribute files, and later files with the same single-value setting take precedence. Read the effective configuration before changing a setting:

$ systemctl cat systemd-logind.service
$ find /etc/systemd/logind.conf.d /run/systemd/logind.conf.d /usr/lib/systemd/logind.conf.d \
    -maxdepth 1 -type f -name '*.conf' -print 2>/dev/null
$ sed -n '1,220p' /etc/systemd/logind.conf 2>/dev/null

The first command shows the service unit and its drop-ins, not the contents of logind.conf. The other commands are a file inventory and an optional read of the main local file. A missing main file is normal when compiled defaults are sufficient. Do not edit a vendor file under /usr; create a clearly named local drop-in if you have a reviewed configuration change.

Warning: KillUserProcesses= is a dangerous distraction to flip casually. Enabling it can terminate processes in a user's session scope at logout and can break tools such as screen and tmux unless they are arranged to run outside that scope. Treat any change to this setting as a deliberate policy change, not a troubleshooting shortcut.

5. Restart only after a service-impact warning

Warning: restarting logind changes the process that owns the login-manager D-Bus service. It may interrupt or alter login and session management, and a mistake made over one SSH connection can leave you without a recovery path. Keep a second administrative connection open and record the current session list first.

If a documented configuration change requires a restart, or the service is genuinely wedged, run:

$ sudo systemctl restart systemd-logind.service

This command changes system state. If it returns successfully, verify both the unit and the login-manager view:

$ systemctl is-active systemd-logind.service
active
$ loginctl list-sessions --no-legend
1 1000 alice - - active no -

The exact sessions and state are host-specific. A successful restart does not repair a bad logind.conf value, a broken PAM stack or a missing D-Bus dependency. If the restart fails, gather evidence before repeating it:

$ systemctl status systemd-logind.service --no-pager --full
$ journalctl -u systemd-logind.service -b --no-pager

Recovery: restore the last known-good configuration, or remove the new local drop-in, then restart once the file contents have been checked. Do not use systemctl enable, disable the service, or repeatedly restart it to hide an underlying configuration or dependency error.

Done means