search

Earnestly / sx

Start an xorg server
MIT License
231 stars 16 forks source link

i3lock not working using systemd service on as sleep hook #26

Closed JosefLitos closed 2 years ago

JosefLitos commented 2 years ago

I have this systemd service file that I use as a screenlock:

[Unit]
Description=Lockscreen app launch before suspend
Before=sleep.target

[Service]
User=%i
Type=forking
Environment=DISPLAY=:0
ExecStart=/usr/bin/i3lock

[Install]
WantedBy=suspend.target

This works well when used with startx. Even when I change the DISPLAY=:0 to DISPLAY=:1, it does nothing but I get no error message whatsoever from i3lock.

This may be a bug with the i3lock itself, but since it appeared only using this programme, I thought it might be more appropriate to put it here.

Earnestly commented 2 years ago

There is no optinality in using the correct environment which is why using services that depend on variable environments is usually the wrong approach. systemctl has import-environment VARIABLE... as a bit of a hack around this problem.

As for sx, it is likely because you need to also include the XAUTHORITY environment due to it not using the default HOME/.XAuthority location. This is where import-environment can help so that you don't have to hardcode the values. (You may also need DBUS_SESSION_BUS_ADDRESS.)

Alternatively consider using xss-lock directly from your sxrc or i3 config as systemd user services interact poorly with dynamic environments like Xorg. DISPLAY, XAUTHORITY, etc. can change by merely switching tty if you're running more than one xserver.

PS: On Arch the example /etc/X11/xinit/xinitrc sources the /etc/X11/xinit/xinitrc.d/50-systemd-user.sh snippet which imports DISPLAY and XAUTHORITY for both the systemd --user and dbus session.