There are numerous utilities to lock the screen of a session. But it is important to note that the utility to use is highly dependant on the environment your 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 to lock a virtual console.
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 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 / 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 environments, 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:
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
When using xss-lock with DPMS, you will have to blank the screen yourself. It will not be triggered when looking at videos
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 the be processed, for exemple by xss-lock.
lock. This will trigger a DBUS notification, that will have to be processed (for exemple 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".
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