Session lock

From ArchWiki
Jump to navigation Jump to search

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#Screen lockers.

By environment

Merge-arrows-2.pngThis article or section is a candidate for merging with List of applications#Screen lockers.Merge-arrows-2.png

Notes: Same purpose, only split into categories. (Discuss in Talk:Session lock#)

Virtual console

You can use vlock or physlock 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:

Most desktop environments come with some way to lock the session.


You can lock the session with

Triggering the lock

You can lock a session using different methods:

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


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 is triggered by one of two things:

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.


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 -- i3lock -n
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 -time 12 -locker "systemctl suspend" -detectsleep

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

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.


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".


Before suspend or hibernate

You can use a Sleep hook.

Description=Lock the screen
ExecStart=/usr/bin/i3lock -c 000000

To enable it for a certain user, use systemctl enable sleep@USERNAME.

Lid closing

You can use the lock action using the related ACPI Event.

See also