BUG `xflock4` relies on the lock handler to return an error code so that it can try the next locker. ```for lock_cmd in \ "$LOCK_CMD" \ "xfce4-screensaver-command --lock" \ "xscreensaver-command -lock" \ "gnome-screensaver-command --lock" do if [ ! -z "$lock_cmd" ]; then $lock_cmd >/dev/null 2>&1 && exit fi done ``` However, `xfce4-screensaver-command --lock` return 0 even it though it didn't engage ``` $ xfce4-screensaver-command --lock ** Message: 15:37:39.938: Screensaver is not running! Start xfce4-screensaver first $ echo $? 0 ``` RELATED: Commit: https://git.xfce.org/xfce/xfce4-session/commit/?id=baf23e096da712084e54b47faa49c1ca99665b75 Old Bug: https://bugzilla.xfce.org/show_bug.cgi?id=2110 SYSTEM ``` $ xfce4-screensaver-command --version xfce4-screensaver-command 0.1.8 $ uname -a Linux bradbury 4.19.69_1 #1 SMP PREEMPT Fri Aug 30 06:44:52 UTC 2019 x86_64 GNU/Linux $ cat /etc/os-release NAME="void" ID="void" DISTRIB_ID="void" PRETTY_NAME="void" ```
Another case when "xfce4-screensaver-command --lock" has exit code 0 even if it does not lock is when "Enable Lock Screen" is set to 0 in screensaver preferences. I think it should return non-zero then, too and let xflock4 use another locker, if possible. BTW why we have '[ ! -z "$lock_cmd" ]' in xflock4, when we could have '[ -n "$lock_cmd" ]' or even '[ "$lock_cmd" ]' there, instead?
Another case when the command should exit with non-zero is when xfce4-screensaver is not running.
(In reply to Jarno Suni from comment #2) > Another case when the command should exit with non-zero is when > xfce4-screensaver is not running. Another option is to start the daemon automatically if needed, which is what gnome-screensaver does. But the main thing is that the locker should not exit with zero, if it fails to lock.
Sean Davis referenced this bugreport in commit 93a49f7d15d2262fe65c58397085711ccb33df69 Return 1 on lock command failure (bug #15945) https://git.xfce.org/apps/xfce4-screensaver/commit?id=93a49f7d15d2262fe65c58397085711ccb33df69
The above commit will make the lock command return 1 when the screensaver is not running. In the case of when the user explicitly disables locking, I think we still want Xfce Screensaver to be the one that honors that decision as opposed to having another installed locker take over.
I question the point of the setting in xfce4-screensaver. If user decides to run xflock4 or click "Lock Screen" in Action Buttons, I think user expects that to lock screen. Luckily user still can set another locker using Xfconf's LockCommand property in xfce4-session channel; just the automatic configuration in xflock4 is ignored currently.
I don't think that's the intention of the lock command options in xflock4. It's more "find which locker the user is using" than "try my hardest to lock the screen". As for xfce4-screensaver, the setting exists for users or configurations that want a screensaver or screen blanking, but no locking. This is valid for kiosks, guest sessions, and live sessions, for a few examples.
The setting should be placed outside xfce4-screensaver so that it is not bind to only that one. xflock4 should exit with non-zero, if it fails to lock. So should 'xfce4-screensaver-command --lock', too. If the aim is to "find which locker the user is using", xflock4 should not try other lockers, if Xfconf LockCommand is set non-null and fails. Consequently xflock4 should begin something like this: # First test for the command set in the session's xfconf channel. LOCK_CMD=$(xfconf-query -c xfce4-session -p /general/LockCommand) if [ "$LOCK_CMD" ]; then $LOCK_CMD exit $? fi # If it was null, try locking by a known screensaver for lock_cmd in \ 'xfce4-screensaver-command --lock' \ 'light-locker-command --lock' \ 'xscreensaver-command -lock' \ 'mate-screensaver-command --lock' \ 'cinnamon-screensaver-command --lock' \ 'gnome-screensaver-command --lock' do $lock_cmd >/dev/null 2>&1 && exit done This way user could effectively choose the same setting by setting LockCommand "false" which is a shell builtin that just exits with 1. "Lock screen with screensaver" setting could still remain in xfce4-screensaver settings. Alternatively, Xfconf could have a distinct setting for disabling lock, possibly so that Xfce does not even run xflock4: it would disable respective settings in Power manager, Action Buttons and xfce4-screensaver.
Even without changing xflock4 user could disable locking by setting LockCommand to "exit 1". (That does not affect to "Lock screen with screensaver" if that does not use xflock4.)