DESCRIPTION: It is no longer running after the system suspends and resumes. After suspend, any attempts at executing `xflock`, be it through the usual keyboard shortcuts or menu buttons, do nothing. Running `xfce4-screensaver-command --lock` returns: ** Message: 11:00:34.866: Screensaver is not running! As a consequence, whenever the system suspends, the screen doesn't lock. If I suspend my system right now and walk away, anyone who gets a hold of my computer will find the session completely unlocked. See system log attached. SYSTEM: I am running Arch Linux with the xfce4-screensaver AUR package (version 0.1.4-2): https://aur.archlinux.org/packages/xfce4-screensaver/ ADDITIONAL INFO: The screen locks successfully when left idle for 10 minutes. After 30 minutes, it suspends. Upon resuming, xfce4-screensaver is no longer running.
Created attachment 8669 output of `journalctl | grep screensaver` Attached `journalctl | grep screensaver` output.
Also, the return value of `xfce4-screensaver-command --lock` is 0 when xfce4-screensaver isn't running, so xflock4 never tries the next possible lock command, just exits with 0 and no output.
(a quick workaround is to use $ xfconf-query -c xfce4-session -p /general/LockCommand -s 'light-locker-command --lock' to make xflock4 go back to light-locker until this is fixed)
(In reply to unhammer+dill from comment #2) > Also, the return value of `xfce4-screensaver-command --lock` is 0 when > xfce4-screensaver isn't running, so xflock4 never tries the next possible > lock command, just exits with 0 and no output. See Bug #15945
Can confirm this bug. Actually the xfce4-screensaver server just stops working. A manual restart (e.g. in user space with nohup) makes it working again. Still not a good thing because you can occassionally not notice your PC actually locked which makes the safety of the "lock" questionable. Consider increasing the priority. Is it the best way to run the xfce4-screensaver on login in userspace via /etc/xdg/autostart? Maybe a systemd service autorestarting itself is more reliable as long as the screenlocker server is instable. Next time the server crashes I will try to get a log of it.
Maybe related: #16102
Fairly certain this is related to #16102. Marking as a duplicate. *** This bug has been marked as a duplicate of bug 16102 ***