# Session lock

From ArchWiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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

This article or section is a candidate for merging with List of applications#Screen lockers.

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.

### 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

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

### Wayland

You can lock the session with swaylock or waylock.

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

##### 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

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

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

#### 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, use `systemctl enable sleep@USERNAME`.

##### 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