Session lock

There are numerous utilities to lock the screen of a session. But it is important to note that the utility to use is highly dependent on the environment you are in, either the virtual console, or a specific display server (Xorg or Wayland).
See
List of applications/Security#Screen lockers
.
By environment
This article or section is a candidate for merging with
List of applications/Security#Screen lockers
.
Notes:
Same purpose, only split into categories. (Discuss in
Talk:Session lock
)
Virtual console
You can use
vlock
or
physlock
AUR
to lock a virtual console.
Xorg
There are many ways to lock the session under Xorg, so this section is likely to be incomplete. Some methods however include:
xlock
, in the
xlockmore
package -
xsecurelock
, in the
xsecurelock
package
xscreensaver-command -lock
in the
xscreensaver
package
xss-lock
slock
in the
slock
package
kscreenlocker
i3lock
i3lock-color
AUR
alock
AUR
Most desktop environments come with some way to lock the session.
Wayland
You can lock the session with one of the following methods:
swaylock
swaylock-effects-git
AUR
waylock
gtklock
hyprlock
Triggering the lock
You can lock a session using different methods:
from a terminal
using a GUI:
from a desktop icon
using hot corners
from a menu (mouse or keyboard driven)
from a
shortcut
from an event:
inactivity (using
systemd
,
xss-lock
or
xautolock
)
systemd events
(suspend, hibernate, etc.)
The last point (triggering a lock from an event) is the trickiest, because you can do it in one of two ways:
get the action trigger to execute your lock, then to execute the initial action.
from the event trigger, add the lock to the event chain. So far this can only be done using systemd.
Shell triggers
Zsh
To execute a command after terminal inactivity, you can use the TMOUT environment variable.
You can combine it with a trap on the ALARM signal to execute the lock. Without a trap, it will just terminate the shell.
You might want to detect if you are in a graphical environment, otherwise your GUI terminals might start disappearing without you understanding why.
Xorg triggers
xss-lock
xss-lock
is triggered by one of two things:
systemd events
DPMS
The advantage of this is that you can control a lock issued manually, by inactivity, and by a suspend command at the same place.
To execute an action on one of those events:
$ xss-lock
locker-utility
systemd events
By default, xss-lock subscribes to
suspend
,
hibernate
,
lock-session
, and
unlock-session
with appropriate actions (run locker and wait for user to unlock or kill locker).
You can prevent xss-lock from being triggered by
suspend
and
hibernate
using
--ignore-sleep
.
You can trigger a manual lock using
loginctl lock-session
, or lock all current sessions with
loginctl lock-sessions
.
DPMS
To configure DPMS signaling timeout:
# Trigger screensaver after 10 minutes of inactivity
xset s on
xset s 600
DPMS signaling can also be configured in
/etc/X11/xorg.conf.d/
in the
Monitor
section.
Using DPMS signaling, you can set a second timer, for example to notify the user or to dim the screen. For example (from
xss-lock(1)
):
# Dim the screen after three minutes of inactivity, lock the screen two minutes later using i3lock:
xset s 180 120
xss-lock -n dim-screen.sh -- i3lock -n
An example
dim-screen.sh
script can be found in
/usr/share/doc/xss-lock
.
Note
When using xss-lock with
DPMS
, you will have to blank the screen yourself. It will not be triggered when looking at videos.
xautolock
Install the
xautolock
AUR
package.
$ xautolock -time 12 -locker "systemctl suspend" -detectsleep
Note
xautolock has restrictive timer limits:
1 min to 1 hour for
time
10 min to 2 hour for
killtime
It might be necessary to add
-detectsleep
to prevent xautolock from locking the session after resuming. One nice feature of xautolock is the
corners
.
Wayland triggers
swayidle
swayidle
listens for idle activity from the Wayland compositor, as well as systemd events, and executes commands accordingly. See
Sway#Idle
.
hypridle
hypridle
Hyprland's idle daemon. See
upstream
for configuration.
D-Bus notification
Using
loginctl lock-session
, or the
lock
action in
logind.conf(5)
, you can notify the system through DBUS that you want to lock. This notification can then be processed, for example by xss-lock.
Inactivity
In
logind.conf(5)
, you can configure the
IdleAction
to
lock
. This will trigger a DBUS notification, that will have to be processed (for example by xsslock) to lock the session.
Note that this is for a global system (so this is not ideal for a multi user environment).
Note also that "this requires that user sessions correctly report the idle status to the system".
Units
Before suspend or hibernate
You can use a
Sleep hook
.
[Unit]
Description=Lock the screen
Before=sleep.target

[Service]
User=%I
Type=forking
Environment=DISPLAY=:0
ExecStart=/usr/bin/i3lock -c 000000

[Install]
WantedBy=sleep.target
To enable it for a certain user,
enable
sleep@
Username
.service
.
Lid closing
You can use the
lock
action using the related
ACPI event
.
See also
Geoff Greer's site: Linux Laptop Locking