How systemd-logind Manages Linux Logins and Power

The systemd-logind daemon is a core system service in modern Linux distributions responsible for tracking user logins, managing active user sessions, and handling physical power events. By integrating directly with the Pluggable Authentication Modules (PAM) architecture and the kernel's ACPI subsystem, systemd-logind ensures that user environments are isolated, system resources are allocated properly, and hardware interactions like pressing the power button or closing a laptop lid are safely and predictably executed.

Core Responsibilities of systemd-logind

The systemd-logind service runs in the background as a system daemon and exposes a comprehensive D-Bus API. Its primary responsibilities include:

• Tracking user seats, sessions, and individual user states.
• Enforcing access policies to hardware devices for unprivileged sessions.
• Allocating per-user and per-session control groups (cgroups).
• Listening to and acting upon system power keys and hardware switches.
• Providing an inhibitor lock mechanism to prevent disruptions during critical operations.

Managing User Logins and Sessions

When a user logs into a Linux machine—whether through a graphical display manager (such as GDM or SDDM), a virtual console (TTY), or an SSH session—the PAM stack triggers the pam_systemd module. This module registers the new session with systemd-logind.

1. Multi-Seat and Multi-Session Management

In Linux, a "seat" refers to a collection of hardware (displays, keyboards, mice) assigned to a single workplace. systemd-logind dynamically assigns hardware devices to specific seats and tracks which session is currently active on each seat. This allows multiple local users to work simultaneously on dedicated sets of hardware without permission conflicts.

2. Device Access Without Root Privileges

Historically, X11 or display servers required root privileges to open graphics devices (/dev/dri/card*) and input devices (/dev/input/*). With systemd-logind, the daemon securely opens file descriptors for these devices and passes them over D-Bus to unprivileged graphical servers (such as Wayland compositors or rootless Xorg). When a session switches to the background, systemd-logind revokes device access, ensuring security between switching users.

3. Session Lifecycle and Isolation

For every logged-in user, systemd-logind creates a user slice in systemd's cgroup hierarchy (user-<UID>.slice) and starts an isolated background instance of systemd --user. This architecture isolates background user processes from system-level services, enforces resource limits, and ensures that lingering background jobs can be terminated cleanly upon logout if configured. Users and administrators can inspect and interact with these sessions using the loginctl command-line utility.

Managing Power Keys and Hardware Events

In addition to login management, systemd-logind serves as the primary handler for low-level ACPI events emitted by physical buttons and hardware sensors.

1. Handling Button Events

When the Linux kernel detects a hardware event, it emits an input event to userspace. systemd-logind listens to these input devices directly and triggers predefined actions. Common events handled by the daemon include:

• Power Key (HandlePowerKey): Typically triggers a graceful system shutdown or power-off.
• Suspend Key (HandleSuspendKey): Suspends the system to RAM.
• Hibernate Key (HandleHibernateKey): Suspends the system to disk.
• Lid Switch (HandleLidSwitch): Suspends laptops when the display lid is closed.
• Lid Switch on External Power (HandleLidSwitchExternalPower): Allows alternate behavior when connected to an external power supply or dock.

These behaviors are configured in /etc/systemd/logind.conf. Available actions for these triggers include ignore, poweroff, reboot, halt, kexec, suspend, hibernate, hybrid-sleep, suspend-then-hibernate, and lock.

2. Inhibitor Locks

To avoid unwanted shutdowns or sleep cycles, systemd-logind implements an inhibitor lock mechanism. Applications can request an inhibitor lock over D-Bus to temporarily block or delay specific power actions. For example:

• A package manager can take a shutdown inhibitor lock to prevent the system from powering down during a system upgrade.
• A media player can take a sleep inhibitor lock to prevent a laptop from suspending while a video is playing.
• A CD/DVD burning utility can inhibit sleep to prevent data corruption.

If an action is triggered while an inhibitor lock is active, systemd-logind will delay the action until the lock is released or a predefined timeout expires.

3. Desktop Environment Integration

Modern desktop environments, such as GNOME and KDE Plasma, communicate with systemd-logind rather than implementing low-level power handling themselves. When a user changes power management settings in a desktop control center, the desktop environment either configures its own response and instructs systemd-logind to ignore the event, or asks systemd-logind to execute the suspension or shutdown directly on its behalf.