systemd-logind doesn’t just track user logins; it actively manages user sessions, acting as the central authority for who’s logged in and what resources they can access.
Let’s see it in action. Imagine a user alice logs in via SSH.
# On the server, as root or a user with sudo
ssh alice@your_server_ip
Once alice is logged in, systemd-logind kicks in. It creates a unique "seat" (like seat0 for the console, or a virtual seat for SSH) and a "session" associated with that seat. This session is tied to alice’s user ID.
# On the server, after alice logs in
loginctl list-sessions
This command will show you an output similar to this:
SESSION UID USER SEAT TTY
1 1000 alice seat0 tty1
2 1000 alice tty2
3 1000 alice ssh ssh-abcdef123456
Here, session 3 represents alice’s SSH login. systemd-logind uses this information to manage resources. For instance, when alice logs out, systemd-logind is responsible for cleaning up her session and any associated processes.
The core problem systemd-logind solves is providing a consistent and secure way to manage user sessions across various login methods (console, graphical, SSH, etc.). Before systemd-logind, managing this was fragmented, often relying on per-service scripts and manual tracking. systemd-logind unifies this by:
- Session Tracking: It knows which users are logged in, on which TTYs or seats, and via which methods.
- Resource Management: It can associate processes with specific sessions. This is crucial for actions like shutting down or rebooting the system –
systemd-logindcan notify active sessions and potentially delay the shutdown if users are active. - User/Group Management: It manages runtime user and group memberships, primarily for session-related privileges. For example, when a user logs in,
systemd-logindmight add them to specific runtime groups. - Power Management: It intercepts power button events and lid closures, coordinating with active sessions before acting.
The exact levers you control are primarily through logind.conf and systemctl.
logind.conf (usually located at /etc/systemd/logind.conf) contains settings like:
NAutoVTs: The number of virtual terminals to automatically create.KillUserProcesses: Whether to kill all processes associated with a user when they log out.KillOnlyInInhibitors: Controls ifKillUserProcessesshould only kill processes that are "inhibited" bysystemd-logind.HandlePowerKey,HandleSuspendKey,HandleHibernateKey,HandleLidSwitch: These define howsystemd-logindreacts to hardware events.
systemctl commands interact with systemd-logind for session management:
loginctl list-sessions: Shows active sessions.loginctl show-session <session_id>: Displays detailed information about a specific session.loginctl terminate-session <session_id>: Kills a session.loginctl kill-user <user_id_or_name>: Kills all sessions for a given user.systemd-login --user --remote=<user>: A lower-level tool to interact with the login manager, often used by other services.
The most surprising thing is how deeply systemd-logind is integrated with the rest of the systemd suite, especially cgroups. When a session is created, systemd-logind places the user’s processes into a dedicated cgroup. This isn’t just for tracking; it allows for fine-grained resource control. For example, systemd services that need to ensure a user’s graphical session has enough resources can leverage these cgroups. When you see processes listed under a specific user’s session via loginctl, they are often living within a very specific slice or scope unit managed by systemd’s cgroup hierarchy, all orchestrated by systemd-logind.
The next step in understanding session management is how systemd-logind interacts with graphical display managers like GDM or SDDM.