Loginctl hooks fail to lock sessions during suspend on OpenRC because the init system does not execute standard systemd sleep scripts or invoke loginctl automatically. To resolve this, you must configure a custom OpenRC hook in /etc/sleep.d that manually calls loginctl lock-session for active users before the system enters the suspended state.
Understanding the Mechanism Mismatch
The core issue arises from a fundamental architectural difference between systemd and OpenRC. On systems managed by systemd, the daemon handles power management events through specific hooks located in/lib/systemd/system-sleep/ or via D-Bus signals. When the system prepares to suspend, systemd triggers these scripts, which often include logic to lock user sessions using loginctl lock-session. This ensures that sensitive data is protected before the RAM is retained in a low-power state.
OpenRC, however, operates independently of systemd. It does not natively understand systemd-specific paths or D-Bus session locking mechanisms in the same way. While OpenRC has its own sleep handling infrastructure, it does not automatically iterate through active login sessions to lock them. If you rely on the default behavior expected from a systemd environment, the sessions will remain unlocked when the machine suspends, leaving your data vulnerable if the device is stolen or accessed while powered off.
This mismatch is particularly noticeable when using desktop environments that expect seamless integration with the underlying init system's power management. Users switching from Ubuntu (which uses systemd) to Debian with OpenRC, or those configuring minimal Linux installations, frequently encounter this gap. The absence of automatic locking is not a bug in OpenRC but a result of its modular design, where such tasks must be explicitly configured by the administrator.
Configuring the OpenRC Sleep Hook
To fix this, you need to create a script that OpenRC will execute during the sleep transition. OpenRC uses the directory/etc/sleep.d for custom scripts that run at various stages of the sleep/wake cycle. These scripts receive arguments indicating the action (e.g., prepare, post, thaw, resume).
Create a new executable file in /etc/sleep.d. A common convention is to name it with a prefix number to control execution order, such as 99-lock-sessions. Ensure the file has execute permissions.
# /etc/sleep.d/99-lock-sessions
#!/bin/sh
case "$1" in
prepare)
# Lock all active sessions before suspending
for session in $(loginctl list-sessions --no-legend | awk '{print $1}'); do
loginctl lock-session "$session"
done
;;
esacprepare. This phase occurs just before the system actually enters the low-power state, providing the perfect window to secure active sessions. The command loginctl list-sessions retrieves all active session IDs. We pipe this output to awk to extract only the first column, which contains the session ID. Finally, we loop through each ID and call loginctl lock-session to enforce the lock.
It is crucial to use prepare rather than suspend directly if available, as some hardware drivers may initialize sleep modes before scripts run. However, on many OpenRC setups, prepare is the most reliable trigger for pre-suspend actions. If your system uses a different trigger mechanism, adjust the case statement accordingly.
Verifying Session State
Before testing, verify that you have active sessions. You can check this by runningloginctl list-sessions in your terminal. If you are logged in via a graphical interface, you should see at least one session. After applying the script, suspend your system using the standard method provided by your desktop environment or by running systemctl suspend (if systemd-shim is installed) or openrc-sleep commands depending on your setup. Upon waking, you should be prompted for a password before accessing the desktop or terminal, confirming that the hook worked correctly.
For more details on how OpenRC manages service shutdowns and ordering, which can sometimes interfere with sleep hooks if misconfigured, see our guide on Preserve Order of Closing Services While Shutting Down Linux.
Alternative Approaches and Desktop Integration
If creating a global hook feels too intrusive, some desktop environments offer their own session locking mechanisms. For instance, KDE Plasma and GNOME have settings within their power management panels that can trigger screen locks before sleep. However, these are often limited to the graphical session and may not lock SSH sessions or TTYs. The OpenRC hook approach is superior because it acts at the system level, ensuring every session managed by logind is secured regardless of how the user interacts with the machine. Another consideration is the interaction with hibernation. If you use hibernation alongside suspend, ensure your hook also handles thehibernate action in the case statement. Hibernation writes memory to disk and powers off completely, making security even more critical.
For users dealing with broader sleep issues, such as systems failing to wake up properly, check your kernel parameters and ACPI tables. Issues with resume states can sometimes mask problems with pre-suspend actions. Our article on Unable to awaken Debian 12 Linux under sleep/suspend provides troubleshooting steps for wake failures that might co-occur with locking issues.
Common Pitfalls
One common mistake is forgetting to make the script executable. Without the execute bit, OpenRC will silently ignore the file. Usechmod +x /etc/sleep.d/99-lock-sessions to fix this.
Another pitfall is assuming that loginctl is always available in the path. In minimal OpenRC installations, you might need to install the util-linux package if it isn't already present, as loginctl is part of this suite. Additionally, ensure that your user has permission to lock other sessions. Usually, root can lock any session, so running the script as root (which OpenRC does for sleep hooks) avoids permission errors.
Finally, test the script manually by calling it with sudo /etc/sleep.d/99-lock-sessions prepare. This simulates the environment without actually suspending the machine, allowing you to check for syntax errors or missing commands.
Frequently Asked Questions
Why doesn't OpenRC lock sessions automatically?
OpenRC is designed to be modular and does not include default behaviors for every possible desktop feature like session locking. Unlike systemd, which integrates deeply with logind, OpenRC requires administrators to explicitly define such interactions through custom scripts in/etc/sleep.d.
Can I use systemd-sleep scripts with OpenRC?
No, OpenRC cannot execute systemd-specific scripts located in/lib/systemd/system-sleep/. These scripts are tied to the systemd daemon lifecycle. You must write native shell scripts compatible with OpenRC's sleep interface instead.
What happens if the lock script fails?
If the script encounters an error, the system will still proceed to suspend unless the script exits with a non-zero status that halts the process. Typically, minor errors in the locking loop won't stop suspension, but the sessions will remain unlocked. Check logs in/var/log/messages or /var/log/syslog for details on why a script might fail.
Does this work for remote SSH sessions?
Yes, becauseloginctl manages all sessions registered with logind, including those created by SSH daemons. The script iterates over all active session IDs, ensuring that remote terminals are also locked before the system sleeps.
How do I disable the lock for specific users?
You would need to modify the script to filter out specific UIDs or usernames. Iterate through the sessions, check the owner of each session usingloginctl show-session, and skip the lock command if the user matches your exclusion list.