It seems rational to request XScreensaver to lock your screen when you suspend your machine. This is possible in Debian via the /etc/default/acpi-support file, especially with this line :
# Comment this out to disable screen locking on resume LOCK_SCREEN=true
However for some obscure reason this will lock the screen (i.e. issue the “xscreensaver-command -lock” command) after suspend, that is on resume. Since the locking process is not immediate your desktop will be available for anyone to watch (and use) for a duration of about one or two second. There is no need to say that this is unacceptable.
It is possible to avoid that by disabling the default screen locking mechanism and hooking it manually to PM. So you should add a script into /etc/pm/sleep.d. The following script is the first version of the script I used (beware it doesn’t work, see below) :
#!/bin/sh
# XScreensaver should be called BEFORE going to sleep to avoid the desktop
# to be shown for a few seconds when the system resumes from sleep.
case "$1" in
hibernate|suspend)
xscreensaver-command -lock
sleep 1 # annoying sleep
;;
*)
exit 0;;
esac
You may notice that the script issues a sleep just after the xscreensaver-command has returned. It ensures that the screen will be really locked when the system effectively enters into sleep. This is needed because the xscreensaver-command will not lock the screen immediately, that is it is non-blocking in a certain way and you cannot ensure that the screen is effectively locked as soon as the command has returned.
However the script above doesn’t work. As Marcus Moeller commented, the above script won’t work by default on Debian and probably with most other distributions. That is because we don’t issue the xscreensaver lock command as the user owning the xscreensaver daemon. I quote his solution here :
#!/bin/sh
# XScreensaver should be called BEFORE going to sleep to avoid the desktop
# to be shown for a few seconds when the system resumes from sleep.
IS_ACTIVE="$( pidof /usr/bin/xscreensaver )"
case "$1" in
hibernate|suspend)
# check if xscreensaver is running. if not, just skip on.
if [ -z "$IS_ACTIVE" ]
then :
else
# run the lock command as the user who owns xscreensaver process,
# and not as root, which won't work.
su "$( ps aux | grep xscreensaver | grep -v grep | grep $IS_ACTIVE | awk '{print $1}' )"
-c "/usr/bin/xscreensaver-command -lock" &
sleep 1
fi
;;
*)
exit 0;;
esac
Digging in xscreensaver’s code shows that what the command actually needs is a connection to the X server. If xscreensaver-command cannot find the display from either command line or environment variables, it will fall back to “:0.0“. But this will fail if root cannot connect to the X server (which is generally the case). That’s how the ‘user approach’ fixes it. However this won’t work anymore if there are multiple instance of xscreensaver running on different displays (only one of them will be locked). Another solution would be to issue the command on each display where root can connect to. However this poses two problems :
- It is not as easy as it seems to reliably list all available displays. (see http://stackoverflow.com/questions/11367354/obtaining-list-of-all-xorg-displays).
- It requires that each lockable session allows connections from root with “xhost si:localuser:root“.
#!/bin/sh
# XScreensaver should be called BEFORE going to sleep to avoid the desktop to be shown
# for a few seconds when the system resumes from sleep.
case "$1" in
hibernate|suspend)
# The X server may not be running
if [ ! -d /tmp/.X11-unix ]
then
exit 0
fi
# Lock each available display
for socket in $(ls /tmp/.X11-unix)
do
display=$(echo "$socket" | tr "X" ":")
xscreensaver-command -display "$display" -lock
done
sleep 1 # annoying sleep
;;
*)
exit 0;;
esac
However we are not done yet. As you can see we still rely on sleep to ensure that the screen is locked before our script returns control to the suspend procedure. With usage it became clear that one second was not sufficient as the script would return too early from time to time. Incrementing the duration of the sleep would be more than annoying and it doesn’t offer any real guarantee anyway. The only solution would be to find a way to exit the script when we are sure that the display is effectively locked. This is possible by watching at the changes of states of the screensaver while issuing the lock command. There is a slight last problem however. If multiple displays are present we want to issue that “lock ‘n watch” procedure in paralell to avoid accumulating the locking delays. That’s the solution I use in the script below, note that we don’t rely on sleep anymore:
#!/bin/sh
# XScreensaver should be called BEFORE going to sleep to avoid the desktop to be
# shown for a few seconds when the system resumes from sleep.
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
lock_display() (
socket="$1"
display=$(echo "$socket" | tr "X" ":")
# Temporary pid file for the watching command
tpid=$(mktemp)
# Wait until the display is actually locked.
(timeout 2s xscreensaver-command -display "$display" -watch & echo $! > $tpid) | (
# Issue the lock command only when we know that
# the watching pipe is ready.
xscreensaver-command -display "$display" -lock
while read line
do
line=$(echo $line | cut -d' ' -f 1)
if [ "$line" = LOCK ]
then
# We have to kill the watching command manually before breaking.
kill -TERM $(cat $tpid)
break
fi
done
)
rm $tpid
)
case "$1" in
hibernate|suspend)
# The X server may not be running
if [ ! -d /tmp/.X11-unix ]
then
exit 0
fi
# Lock each available display
for socket in $(ls /tmp/.X11-unix)
do
# Lock the display
lock_display $socket &
done
# Wait until every displays are locked
wait
;;
*)
exit 0;;
esac
As stated above you still need to allow connections from root to your display. You may for example use this command when your session start :
xhost si:localuser:root
Or, as the man page of xhost states, use the file /etc/X*.hosts to do that globally.
As xscreensaver runs in the user context (at least on Wheezy), I have modified your script a little to:
#!/bin/sh
# XScreensaver should be called BEFORE going to sleep to avoid the desktop
# to be shown for a few seconds when the system resumes from sleep.
IS_ACTIVE=”$( pidof /usr/bin/xscreensaver )”
case “$1” in
hibernate|suspend)
# check if xscreensaver is running. if not, just skip on.
if [ -z “$IS_ACTIVE” ]
then :
else
# run the lock command as the user who owns xscreensaver process,
# and not as root, which won’t work.
su “$( ps aux | grep xscreensaver | grep -v grep | grep $IS_ACTIVE | awk ‘{print $1}’ )”
-c “/usr/bin/xscreensaver-command -lock” &
sleep 1
fi
;;
*)
exit 0;;
esac
Thanks for pointing this.
Digging in the code shows that what the command actually needs is a connection to the X server. If xscreensaver-command cannot find the display from either command line or environment variables, it will fall back to “:0.0”. But this will fail if root cannot connect to the X server (which is generally the case). That’s why the ‘user approach’ fixes it. However this won’t work anymore if there are multiple instance of xscreensaver running on different displays (only one of them will be locked). Another solution would be to issue the command on each display where root can connect to. However this poses two problems :
1) It is not as easy as it seems to list available displays.
(see http://stackoverflow.com/questions/11367354/obtaining-list-of-all-xorg-displays).
2) It requires that each lockable session allows connections from root with “xhost si:localuser:root”.
Here is a modification of the script which takes the ‘display approach’:
#!/bin/sh
# XScreensaver should be called BEFORE going to sleep to avoid the desktop to be shown
# for a few seconds when the system resumes from sleep.
case “$1” in
hibernate|suspend)
# The X server may not be running
if [ ! -d /tmp/.X11-unix ]
then
exit 0
fi
# Lock each available display
for socket in “$(ls /tmp/.X11-unix)”
do
display=$(echo “$socket” | tr “X” “:”)
xscreensaver-command -display “$display” -lock
done
sleep 1 # annoying sleep
;;
*)
exit 0;;
esac
Have you been able to adopt this to systemd, already
I don’t use Linux on my laptop anymore so I did not look into this. 🙂
Instead on FreeBSD I can use /etc/rc.suspend.
However for systemd, I read there:
http://www.freedesktop.org/software/systemd/man/systemd-suspend.service.html
“systemd-suspend.service is a system service that is pulled in by suspend.target and is responsible for the actual system suspend.”
(…)
“Immediately before entering system suspend and/or hibernation systemd-suspend.service (and the other mentioned units, respectively) will run all executables in /usr/lib/systemd/system-sleep/ and pass two arguments to them. The first argument will be “pre”, the second either “suspend”, “hibernate”, or “hybrid-sleep” depending on the chosen action. Immediately after leaving system suspend and/or hibernation the same executables are run, but the first argument is now “post”. All executables in this directory are executed in parallel, and execution of the action is not continued until all executables have finished.
Note that scripts or binaries dropped in /usr/lib/systemd/system-sleep/ are intended for local use only and should be considered hacks. If applications want to be notified of system suspend/hibernation and resume, there are much nicer interfaces available.”
So I guess you have to put the script there and check that you are in pre-suspend ($1 = pre). On Debian it seems to be in /lib/systemd/system-sleep.
Thank you very much for this writeup. It is still applicable in 2022 on (systemd-free) void linux w/out a login manager.
I don’t know whether this fact should be read as a positive (backwards compatibility, stability of xscreensaver’s behavior), or as a negative (locking screen on suspend is still messed up).
I know systemd “solves” this particular issue, but I don’t want to invite that particular vampire into my house.