1

I am using the i3 tiling windows manager in combination with light-locker to lock the screen.

Light-locker displays a lock message on the locked TTY and shows the password screen on a second TTY.

When closing the notebook lid or executing systemctl suspend from a terminal emulator, the lock messages appears for a short time, then the system goes into S3 state. On resume, the lock message is visible for a short time again, then light-locker switches to the password entry-TTY, which is the desired behaviour.

The problem occurs when I bind the systemctl command to a specific key via the i3 config file like this:

bindsym s exec --no-startup-id systemctl suspend, mode "default"

When pressing $mod + s, the screen turns black immediately, not showing the lock message.

On resume, the screen turns on, displaying the unlocked desktop for a half second, then the lock messages flashes for the fraction of a second and then the password entry-TTY is shown.

This behaviour is not acceptable, as it exposes the desktop after suspending the computer, even the desktop is only visible for a short time.

My guess is, that when using bash to execute systemctl suspend, the command takes longer time or sth. like that, making it possible for light-locker to switch to the lock message before the system suspends.

How can I avoid or circumvent the different behaviour of the key binding?

  • Use a script or something that explicitly locks the screen then calls suspend. – goldilocks Jan 7 '14 at 12:29
  • Unfortunately, after calling the command to explictly lock the screen, the suspend command gets not executed. – Alexander Willer Jan 7 '14 at 13:37
3

I was able to solve problem by using the following commands:

(sleep 0.5 && systemctl suspend) &

It would be interesting to know, why exactly the sleep command is needed to get the desired behaviour.

  • Did you have that '&' fork in there at all before? If i3's exec waits, that would affect behaviour. Evidently light locker was catching a signal after the suspend resumes, as if it and i3 were suspended until the exec completed, whereas when run from a shell that is not an issue. Forking it off allows them to resume and catch the signal from suspend without it being deferred. – goldilocks Jan 7 '14 at 14:05

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.