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).
- 1 By environment
- 2 Triggering the lock
- 2.1 List of triggers
- 2.2 Shell triggers
- 2.3 Xorg triggers
- 2.4 Wayland triggers
- 2.5 systemd triggers
- 3 Actions after the lock has been triggered
- 4 See also
You can use
vlock or to lock a virtual console.
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 package -
xsecurelock, in the package
xscreensaver-command -lockin the package
slockin the package
Most desktop environments come with some way to lock the session.
You can lock the session with
swaylock in the package .
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:
- another action (suspend, hibernate, ...)
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.
List of triggers
Suspend and hibernate
Service file dependency Hook to xss-lock
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.
is triggered by one of two things:
- systemd events
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>
By default, xss-lock subscribes to
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
You can trigger a manual lock using loginctl lock-session.
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
Using DPMS signaling, you can set a second timer, for example to notify the user or to dim the screen. For example (from):
# Dim the screen after three minutes of inactivity, lock the screen two minutes later using i3lock: xset 180 120 xss-lock -n dim-screen.sh -- i3lock -n
$ xautolock -time 12 -locker "systemctl suspend" -detectsleep
xautolock has restrictive timer limits:
- 1 min to 1 hour for
- 10 min to 2 hour for
It might be necessary to add
-detectsleep to prevent xautolock from locking the session after resuming.
One nice feature of xautolock is the
loginctl lock-session, or the
lock action in , you can notify the system through DBUS that you want to lock. This notification can then be processed, for example by xss-lock.
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".
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, use
systemctl enable sleep@USERNAME.
You can use the
lock action using the related ACPI Event.
Actions after the lock has been triggered
Suspend/Hibernate after X Shudown screen