I have some troubles with using slock with void linux. I tried adding slock as a script to zzz: /etc/zzz.d/suspend/slock


which works in a strange way: if I call zzz, it brings up slock and doesn't suspend until I enter my password and unlock. I moved the script to /etc/zzz.d/resume/slock, now on resume it flashes unlocked screen for a second and then locks the screen, which is not so good but fine.

But there is another problem: closing the lid suspends the laptop but it doesn't lock the screen at all. I thought it might have something to do with acpid. When I disable acpid, closing lid doesn't suspend the laptop, so acpid is definitely responsible for this. I tried to tinker with /etc/acpi/handler.sh, now it looks like this:

                        # suspend-to-ram
                        logger "LID closed, suspending..."
                open)   logger "LID opened" ;;
                *) logger "ACPI action undefined (LID): $2";;

and slock is not executed anyways. I tried removing zzz from handler.sh, then closing the lid doesn't do anything, which means it actually executes zzz when it's present but doesn't execute zzz's user scripts for some reason. I also tried replacing slock with i3lock in both handler.sh (like void wiki suggests) and zzz.d/resume but it's the same. Did I do something wrong or is there another reason for this behavior?


Your initial solution does not work because the shell waits for the slock process to stop before continuing. The easiest (but not best) solution to to make the command slock & which allows processes to continue after. However, this does not guarentee slock will finish running before the device suspends.

The "proper" way to do this would be using xss-lock to call slock, and using xset to lock the screen on command. Both of these can be found in Void's repositories. xss-lock slock would set xss-lock to use slock for locking.

This should work without any additional scripts, as xss-lock is supposed to act on suspend normally. However, suspend-based events have always been buggy, so an additional activation through xset isn't a bad idea.

An example /etc/zzz.d/suspend/slock would be

xset s activate

A similar script could be placed in the respective "resume" file, but the previous issue of an unlocked screen showing up before the lock screen would still appear.


Tinkered this issue like this:


doas -u ds xsecurelock &
sleep 2


permit persist :wheel
permit nopass root as ds cmd xsecurelock
permit nopass :wheel as root cmd zzz
permit nopass :wheel as root cmd ZZZ
permit nopass keepenv root as root

You can try to define $DISPLAY for root user in suspend script, but I'm too stupid to solve this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.