Jump to content

# Session lock

From ArchWiki

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 physlockAUR 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-colorAUR
- alockAUR

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-gitAUR
- 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 xautolockAUR 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

Category:

- Security

Hidden category:

- Pages or sections flagged with Template:Merge

Session lock
Add topic