systemd-logind is quietly controlling more of your system than you realize.
Why does closing the laptop lid suspend the system?
Why does pressing the power button shut it down?
Why do processes sometimes survive logout?
Why can applications prevent the system from sleeping?
Why does Linux provide multiple virtual terminals?
A large part of the answer is systemd-logind.
Its primary configuration file is:
/etc/systemd/logind.conf
The file controls login sessions, virtual terminals, power and sleep keys, laptop-lid events, idle actions, user-process cleanup, runtime directories, and inhibitor locks. The official systemd documentation describes logind.conf as the configuration file for the systemd login manager.
Important:
logind.confis powerful. A small configuration change can affect how a laptop sleeps, how remote sessions behave, or whether user processes survive logout. Always make a backup before modifying it.
1. What Is systemd-logind?
systemd-logind is the systemd component responsible for managing user logins and sessions.
It keeps track of things such as:
- Logged-in users
- User sessions
- Seats
- Virtual terminals
- Graphical and text sessions
- Power-button events
- Suspend/hibernate events
- Laptop-lid events
- Idle state
- User runtime directories
- Session-related cleanup
- Inhibitor locks
It also exposes this information through the systemd login manager interface, which tools such as loginctl can query and control.
Think of it as a bridge between physical hardware events, user sessions and system power management.
┌─────────────────────┐ │ Hardware │ │ │ │ Power Button │ │ Lid Switch │ │ Sleep Key │ │ Hibernate Key │ └──────────┬──────────┘ │ ▼ ┌──────────────────┐ │ systemd-logind │ └────────┬─────────┘ │ ┌───────────────┼────────────────┐ ▼ ▼ ▼ Sessions Power State Virtual TTYs │ │ │ ▼ ▼ ▼ loginctl suspend getty hibernate poweroff
2. Where Is logind.conf?
The primary administrator configuration file is:
/etc/systemd/logind.conf
Inspect it with:
sudo cat /etc/systemd/logind.conf
Or:
sudo nano /etc/systemd/logind.conf
You can also inspect the currently running logind service:
systemctl status systemd-logind
And inspect sessions:
loginctl
For more detailed information:
loginctl list-sessions
loginctl session-status
The loginctl utility is specifically intended to inspect and control the systemd login manager.
3. Virtual Terminals — NAutoVTs and ReserveVT
Linux normally provides multiple virtual terminals (VTs).
You can commonly switch between them with:
Ctrl + Alt + F1 Ctrl + Alt + F2 Ctrl + Alt + F3 ...
The exact VT used by the graphical session can vary between distributions and configurations.
NAutoVTs=6
Example:
NAutoVTs=6
This controls how many virtual terminals are automatically allocated for autovt@.service.
These VTs provide text-based login sessions.
You can see active sessions with:
loginctl
And inspect the virtual terminals:
ls /dev/tty*
Why is this useful?
On a troubleshooting machine, VTs are extremely useful.
If your graphical desktop crashes, you can switch to a text console and investigate:
Ctrl + Alt + F3
Then log in and run:
systemctl status
or:
journalctl -b -p err
4. ReserveVT=6
Example:
ReserveVT=6
This deserves an important clarification.
ReserveVT does not specifically reserve VT6 for the graphical desktop.
It reserves the selected VT for autovt@.service, ensuring that a login getty remains available there even if other components allocate VTs. The systemd documentation gives VT6 as the traditional default.
So:
ReserveVT=6
essentially means:
Keep VT6 available for a text login.
This can be particularly useful when debugging a graphical environment.
5. User Process Cleanup
One of the most interesting settings is:
KillUserProcesses=no
What does it mean?
When a user completely logs out, systemd-logind normally has the ability to terminate processes belonging to that user.
With:
KillUserProcesses=no
those processes are not automatically killed merely because the user's last session ended.
This can be useful for:
-
tmux -
screen - Long-running scripts
- Background development processes
- Certain server-side workflows
The official documentation confirms that KillUserProcesses= determines whether user processes are killed when the user completely logs out.
6. KillOnlyUsers=
Example:
KillOnlyUsers=
This allows you to specify particular users whose processes should be subject to the process-killing policy.
For example:
KillOnlyUsers=alice bob
This is useful when you want different process-lifecycle behavior for different accounts.
7. KillExcludeUsers=
Example:
KillExcludeUsers=root
This defines users excluded from the KillUserProcesses= policy.
The default configuration commonly excludes root.
This is particularly important because administrator processes should not casually be terminated as a side effect of another user's logout.
8. Shutdown and Sleep Delays
InhibitDelayMaxSec=
Example:
InhibitDelayMaxSec=5
This controls how long a delay-type inhibitor lock can postpone a shutdown or sleep operation.
For example, an application may need a short amount of time to:
- Save state
- Flush data
- Finish a critical operation
- Prepare for suspend
- Prepare for shutdown
With:
InhibitDelayMaxSec=5
the delay is capped at five seconds before the inhibitor is ignored and the operation proceeds.
This is different from an application simply blocking the operation indefinitely.
9. UserStopDelaySec=
This setting controls how long the per-user systemd service manager remains active after the user's last session ends.
For example:
UserStopDelaySec=10
means the user manager can remain around for a short period after logout before being stopped.
This can be useful for avoiding unnecessary startup/shutdown churn when a user logs out and logs back in shortly afterward.
10. Sleep Operations
A configuration might contain:
SleepOperation=suspend-then-hibernate suspend
This defines the preferred sleep operation sequence.
For example:
Suspend │ │ after configured conditions/time ▼ Hibernate
This can provide a compromise between:
- Fast resume
- Lower battery consumption
- Protection against complete battery depletion during long periods of sleep
The exact availability and behavior of sleep states depends on the hardware, kernel and system configuration.
11. Power Button Behavior
One of the most commonly customized options is:
HandlePowerKey=poweroff
This tells logind to handle the power-button event by powering the machine off.
Other possible actions include:
ignore poweroff reboot halt kexec suspend hibernate hybrid-sleep lock
The official logind.conf documentation lists these actions for power/sleep/lid handling.
For example:
HandlePowerKey=lock
would make the power button lock sessions instead of powering off.
12. Long Press Power Button
Example:
HandlePowerKeyLongPress=ignore
This controls the software handling of a long power-button press where supported.
It is important to distinguish this from physically holding the power button until the firmware/hardware forces power off.
That hardware-level emergency shutdown is outside the normal systemd-logind policy.
13. Reboot Button
If hardware exposes a dedicated reboot key/button, settings such as:
HandleRebootKey=reboot
can determine what logind does with that event.
A long press can have its own action:
HandleRebootKeyLongPress=poweroff
So you can potentially have:
Short press → Reboot Long press → Power off
Whether these events are available depends on the hardware and input subsystem.
14. Suspend and Hibernate Keys
Suspend:
HandleSuspendKey=ignore
Hibernate:
HandleHibernateKey=hibernate
These determine what logind does when corresponding hardware events are received.
For example:
HandleSuspendKey=suspend
would allow the suspend key to initiate suspend.
While:
HandleSuspendKey=ignore
tells logind not to handle that event.
15. Long-Press Actions
Modern systemd versions can distinguish between normal and long-press events where the relevant hardware/input event is supported.
For example:
HandleSuspendKeyLongPress=hibernate
can define a different action for a long press.
This gives you a useful hierarchy:
Suspend key │ ├── Short press → Suspend │ └── Long press → Hibernate
16. The Most Useful Laptop Setting: Lid Switch
Laptop users often modify:
HandleLidSwitch=
This determines what happens when the laptop lid is closed.
A typical default is:
HandleLidSwitch=suspend
But a server-style laptop might use:
HandleLidSwitch=ignore
This means:
Closing the lid does not cause logind to perform its configured action.
The systemd documentation explicitly supports lid-switch actions such as ignore, poweroff, reboot, suspend, hibernate, hybrid-sleep, and lock.
17. Lid + External Power
You can configure a separate behavior when connected to AC power:
HandleLidSwitchExternalPower=ignore
For example:
Battery + lid closed ↓ Suspend AC power + lid closed ↓ Keep running
This is useful for laptop servers.
Imagine an old laptop running:
- Apache
- MariaDB
- Docker
- SSH
- Ollama
- Home-lab services
You may want to close the lid without shutting down the server.
18. Lid + Docking Station
Another useful setting is:
HandleLidSwitchDocked=ignore
This affects behavior when the system is considered docked or when multiple displays are connected.
The systemd documentation notes that the docked behavior can apply when the machine is in a docking station or when more than one display is connected.
A common laptop-server configuration therefore looks conceptually like:
HandleLidSwitch=ignore HandleLidSwitchExternalPower=ignore HandleLidSwitchDocked=ignore
That effectively prevents lid closure from triggering the usual suspend behavior in those cases.
19. Inhibitor Locks
One of the more powerful concepts in systemd-logind is the inhibitor lock.
Applications can tell logind:
"Please don't perform this operation right now."
For example:
Video player │ ▼ "I am playing a movie" │ ▼ Prevent automatic suspend
You can inspect inhibitor locks using:
systemd-inhibit --list
This is extremely useful when troubleshooting why a machine refuses to sleep or shut down.
20. PowerKeyIgnoreInhibited
Example:
PowerKeyIgnoreInhibited=no
When set to no, inhibitor locks can affect the action associated with the power key.
If set to:
PowerKeyIgnoreInhibited=yes
the configured power-key action is performed even when an application has taken the corresponding inhibitor lock.
The same concept applies to:
SuspendKeyIgnoreInhibited= HibernateKeyIgnoreInhibited= LidSwitchIgnoreInhibited=
The systemd documentation describes these options as controlling whether power/sleep/lid actions are subject to inhibitor locks.
21. Why LidSwitchIgnoreInhibited=yes Is Interesting
A configuration such as:
LidSwitchIgnoreInhibited=yes
means that applications' inhibitor locks do not prevent the lid-switch action.
This can be useful if you want:
Close lid ↓ Always obey logind's lid policy
rather than allowing a desktop application to override it.
22. HoldoffTimeoutSec
Example:
HoldoffTimeoutSec=30s
This provides a period during which lid events can be temporarily ignored after relevant boot/resume situations.
The purpose is to avoid undesirable behavior during the period when hardware and docking devices are still being initialized.
This becomes particularly relevant for laptops connected to docks or external displays.
23. Automatic Idle Actions
Two settings work together:
IdleAction=ignore IdleActionSec=30min
IdleAction defines what to do.
IdleActionSec defines how long the system must remain idle before doing it.
For example:
IdleAction=lock IdleActionSec=30min
conceptually means:
No activity │ ▼ 30 minutes │ ▼ Lock sessions
The official documentation specifies that the action is only taken after sessions report themselves idle, no idle inhibitor is active, and the configured delay has expired.
24. IdleAction=ignore
If you have:
IdleAction=ignore
then logind does not perform an automatic idle action.
Even if:
IdleActionSec=30min
is configured, there is no action to execute.
Therefore:
IdleAction=ignore IdleActionSec=30min
does not mean:
Lock after 30 minutes.
It means:
No logind idle action.
25. Runtime Directory
Linux provides each logged-in user with a runtime directory, commonly:
/run/user/<UID>
This is represented by:
$XDG_RUNTIME_DIR
You can check yours with:
echo "$XDG_RUNTIME_DIR"
For example:
/run/user/1000
26. RuntimeDirectorySize=10%
Example:
RuntimeDirectorySize=10%
This limits the size of each user's runtime directory relative to physical RAM.
The systemd documentation states that the default is 10% of physical memory. It is a safety limit rather than an allocation that immediately consumes that amount of RAM. The runtime directory is backed by tmpfs and only consumes memory as needed.
For example, with:
32 GB RAM
a 10% limit corresponds approximately to:
3.2 GB
as the runtime-directory size limit.
27. RuntimeDirectoryInodesMax=
A filesystem has two important resource concepts:
Storage capacity + Inodes
A directory can run out of inodes even when it still has free space.
RuntimeDirectoryInodesMax= allows you to control the maximum number of inodes available for user runtime directories.
Leaving it unset allows systemd to use its default behavior.
28. RemoveIPC=yes
Example:
RemoveIPC=yes
IPC means Inter-Process Communication.
Linux provides several IPC mechanisms, including:
- Shared memory
- Semaphores
- Message queues
With RemoveIPC=yes, systemd-logind removes the user's relevant IPC objects when the user completely logs out.
The official documentation confirms that this covers System V and POSIX IPC objects and that root's IPC objects are excluded.
This helps prevent logged-out users from retaining IPC resources indefinitely.
29. Inhibitor Limits
Example:
InhibitorsMax=8192
This limits the number of inhibitor locks that can be registered.
An inhibitor can relate to operations such as:
shutdown sleep idle
You can inspect active inhibitors with:
systemd-inhibit --list
30. Session Limits
Example:
SessionsMax=8192
This limits the number of simultaneously tracked login sessions.
For a normal desktop or home server, you are unlikely to approach such a limit.
On systems hosting many users or automated sessions, however, session accounting can become relevant.
31. StopIdleSessionSec=infinity
Example:
StopIdleSessionSec=infinity
This means idle sessions are not automatically stopped based on this timeout.
That can be useful for:
- Development machines
- Remote administration
- Long-running SSH sessions
- Home labs
- Test systems
But keeping sessions alive indefinitely can also mean keeping resources associated with those sessions around longer.
32. DesignatedMaintenanceTime=
Example:
DesignatedMaintenanceTime=
An empty value means no maintenance time has been configured through this setting.
This option can be used by systemd components that support designated maintenance scheduling.
For most desktop users, it can safely remain unset.
33. WallMessages=yes
Example:
WallMessages=yes
This allows system-wide warning messages to be broadcast to logged-in terminal users.
For example, administrators can notify users that a system shutdown is about to happen.
A classic example is:
wall "System maintenance begins in 5 minutes"
This is particularly useful on:
- Multi-user servers
- SSH systems
- Terminal servers
- University/lab environments
34. A Practical Laptop-Server Configuration
Suppose you have an old laptop that you have converted into a Linux home server.
You want:
- SSH to remain available
- Apache to keep running
- Docker containers to keep running
- The machine not to suspend when the lid closes
- User processes to survive logout
- No automatic idle shutdown
A configuration might look like:
[Login] NAutoVTs=6 ReserveVT=6 KillUserProcesses=no HandlePowerKey=poweroff HandlePowerKeyLongPress=ignore HandleSuspendKey=ignore HandleSuspendKeyLongPress=hibernate HandleHibernateKey=hibernate HandleHibernateKeyLongPress=ignore HandleLidSwitch=ignore HandleLidSwitchExternalPower=ignore HandleLidSwitchDocked=ignore PowerKeyIgnoreInhibited=no SuspendKeyIgnoreInhibited=no HibernateKeyIgnoreInhibited=no LidSwitchIgnoreInhibited=yes IdleAction=ignore IdleActionSec=30min RuntimeDirectorySize=10% RemoveIPC=yes InhibitorsMax=8192 SessionsMax=8192 StopIdleSessionSec=infinity WallMessages=yes
Do not blindly copy this configuration. The appropriate values depend on whether the machine is a laptop, desktop, server, workstation, or remotely administered system.
35. How to Safely Modify logind.conf
Before making changes:
sudo cp /etc/systemd/logind.conf \ /etc/systemd/logind.conf.backup
Edit:
sudo nano /etc/systemd/logind.conf
Then restart logind:
sudo systemctl restart systemd-logind
Important warning
Restarting systemd-logind can affect active sessions and desktop environments.
On a remote machine, be especially careful.
If you are connected through:
SSH RDP VNC
do not make session-management changes blindly.
36. Verify Your Configuration
Check the service:
systemctl status systemd-logind --no-pager
List sessions:
loginctl list-sessions
List users:
loginctl list-users
List seats:
loginctl list-seats
Inspect inhibitors:
systemd-inhibit --list
Inspect logs:
journalctl -u systemd-logind
For the current boot:
journalctl -u systemd-logind -b
And for errors:
journalctl -u systemd-logind -b -p err
37. A Useful Troubleshooting Workflow
If your laptop unexpectedly suspends when you close the lid:
Step 1 — Check configuration
grep -E \ '^(HandleLidSwitch|HandleLidSwitchExternalPower|HandleLidSwitchDocked|LidSwitchIgnoreInhibited)' \ /etc/systemd/logind.conf
Step 2 — Check inhibitors
systemd-inhibit --list
Step 3 — Check logind
systemctl status systemd-logind --no-pager
Step 4 — Check logs
journalctl -u systemd-logind -b --no-pager
Step 5 — Inspect sessions
loginctl
This usually gives you enough information to determine whether the problem is:
Configuration ↓ Inhibitor ↓ Desktop environment ↓ logind ↓ Kernel / hardware
38. logind.conf Is Not the Same as GNOME Settings
This is particularly important on GNOME systems.
There can be multiple layers involved:
Hardware │ ▼ Kernel / ACPI / input subsystem │ ▼ systemd-logind │ ├── GNOME ├── GDM ├── systemd user manager └── Applications
Therefore, changing:
HandleLidSwitch=ignore
doesn't mean every component on the machine has been configured identically.
Desktop environments can also participate in power-management decisions and use inhibitor locks.
This is why troubleshooting laptop sleep problems should include both:
systemd-inhibit --list
and:
loginctl
rather than changing random settings until the problem disappears.
39. Why logind.conf Matters for Home Servers
An old laptop can make a surprisingly capable home server.
You might run:
Ubuntu / Debian / Kali │ ├── SSH ├── Apache ├── MariaDB ├── Docker ├── Ollama ├── Open WebUI ├── RDP └── Monitoring Dashboard
But laptop power-management defaults can work against that goal.
For example:
Close laptop lid ↓ Suspend ↓ Network services disappear ↓ SSH unavailable ↓ Docker services stop responding ↓ Web server disappears
Understanding systemd-logind lets you intentionally configure the machine instead of fighting the default behavior.
40. Quick Reference Table
| Setting | Purpose |
|---|---|
NAutoVTs= | Number of automatically allocated VTs |
ReserveVT= | Reserves a VT for an autovt/getty login |
KillUserProcesses= | Kill user processes after complete logout |
KillOnlyUsers= | Apply process killing to specified users |
KillExcludeUsers= | Exclude users from process killing |
InhibitDelayMaxSec= | Maximum delay from delay inhibitors |
UserStopDelaySec= | Delay before stopping a user's service manager |
HandlePowerKey= | Power-button action |
HandlePowerKeyLongPress= | Long-press power action |
HandleRebootKey= | Reboot-button action |
HandleSuspendKey= | Suspend-key action |
HandleHibernateKey= | Hibernate-key action |
HandleLidSwitch= | Lid-close action |
HandleLidSwitchExternalPower= | Lid behavior on AC |
HandleLidSwitchDocked= | Lid behavior while docked/multi-display |
*IgnoreInhibited= | Whether inhibitor locks are respected |
IdleAction= | Action after system becomes idle |
IdleActionSec= | Idle timeout |
RuntimeDirectorySize= | $XDG_RUNTIME_DIR size limit |
RuntimeDirectoryInodesMax= | Runtime-directory inode limit |
RemoveIPC= | Remove user's IPC objects after logout |
InhibitorsMax= | Maximum inhibitor locks |
SessionsMax= | Maximum login sessions |
StopIdleSessionSec= | Idle-session stopping timeout |
DesignatedMaintenanceTime= | Maintenance scheduling parameter |
WallMessages= | Enable system-wide terminal broadcasts |
Final Takeaway
/etc/systemd/logind.conf may look like a collection of obscure settings, but it actually controls a major part of the relationship between Linux users, sessions, hardware buttons and power management.
The most important settings for everyday Linux users are probably:
KillUserProcesses= HandlePowerKey= HandleSuspendKey= HandleHibernateKey= HandleLidSwitch= HandleLidSwitchExternalPower= HandleLidSwitchDocked= PowerKeyIgnoreInhibited= SuspendKeyIgnoreInhibited= HibernateKeyIgnoreInhibited= LidSwitchIgnoreInhibited= IdleAction= IdleActionSec= RuntimeDirectorySize= RemoveIPC=
For a laptop being used as a 24/7 home server, the lid-related options and process/session settings are especially important.
And if you ever wonder:
“Why did Linux suspend when I closed the lid?”
or
“Why did my process disappear after logout?”
systemd-logind is one of the first places you should investigate.
Official systemd `logind.conf` documentation
Official `loginctl` documentation
No comments:
Post a Comment
Thank you for Commenting Will reply soon ......