Suspending Lubuntu when the "Lock Screen After" box is checked in XScreenSaver results in an error message about xdg-screensaver

[Aaron Rainbolt]

Test hardware - HP Elitebook 8570p, 16 GB RAM, 1 TB SSD, 3rd gen i5 CPU. Test was done within a GNOME Boxes VM, 2 GB RAM, 20 GB disk space, SeaBIOS.

Steps to reproduce:

1: Install Lubuntu 22.04 into a VM.
2: Run "sudo apt update && sudo apt -y full-upgrade" to get the VM up-to-date.
3: Reboot the VM.
4: Open XScreenSaver, and check the "Lock Screen After" box.
5: Close XScreenSaver.
6: Click the Application Menu, hover over "Leave", and click "Suspend", then click "OK".

Expected result:
The VM should immediately go into sleep mode without any errors.

Actual result:
The screen goes black, then the following text appears on the screen:

    xscreensaver: XX:XX:XX: not launching hack (throttled.)
    xscreensaver: XX:XX:XX: LOCK CLientMessage received while already locked.

If you move the mouse, an XScreenSaver prompt will appear asking for your username and password. If you simply leave the VM for long enough it will eventually go into suspend. If you sign in, the following error message will be present on the screen in a window:

    Failed to run "xdg-screensaver lock". Ensure you have a locker/screensaver compatible with xdg-screensaver installed and running.

Leaving the VM alone at this point will also eventually result in it going into suspend. Clicking the "OK" button on the error window will result in the VM immediately suspending.

Notes:

I don't actually know what package this should be reported against - I chose lxqt-session because a look at the LXQt source code revealed that it was possible that the "Suspend" button in the LXQt Application Menu was from lxqt-session. Other packages this bug might be in include XScreenSaver, liblxqt, lxqt-powermanagement, systemd, or whatever provides DBus (is that even provided by a package? *shrug*).

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: lxqt-session 0.17.1-0ubuntu1
ProcVersionSignature: Ubuntu 5.15.0-41.44-generic 5.15.39
Uname: Linux 5.15.0-41-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.1
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: LXQt
Date: Mon Jul 25 02:04:25 2022
InstallationDate: Installed on 2022-07-25 (0 days ago)
InstallationMedia: Lubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419)
SourcePackage: lxqt-session
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Chris Guiver (guiverc)]

This was reported by a user on IRC (#lubuntu).

> Failed to run "xdg-screensaver lock". Ensure you have a locker/screensaver compatible with xdg-screensaver installed and running.

I experienced it on my own system (thinkpad x201), but initially had issues trying to re-create it elsewhere so no bug was filed.

I assumed (wrongly) it was LXQt 1.1 related (nope!) but it was the LOCK SCREEN AFTER box that needs to be checked.. new installs (I tested on) lacked this.

Experienced on (both running Lubuntu jammy)
- lenovo thinkpad x201 (i5-m520, 4gb, i915) [fully upgraded]
- hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290) [20220724 daily]

x201 being a used system of mine, dc7700 a clean install where I added LXQt via backports and again failed to re-create issue..

Issue was finally & only created when LOCK SCREEN AFTER box is checked, which I had on my used x201, but was lacking on my prior attempts to re-create this issue on fresh installs (as it's not default).

[Chris Guiver (guiverc)]

I had another fresh install of Lubuntu jammy [20220724] on
- hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)

To re-create it required

- open (x)screensaver preferences
- click LOCK SCREEN AFTER 0 minutes
(delayed a little here but I didn't close window)
- suspend system...

Messages occur as per Aaron's report.

This is a default 22.04 install using LXQt 0.17 (using daily; install-alongside testcase caused two installs)

[thedoctar (thedoctar)]

Could this be a clash between lxqt-powermanagement and Xscreensaver? Both have options about suspending the system after a certain amount of idle time.

[thedoctar (thedoctar)]

I no longer have this problem after upgrading xserver and kidletime (manually using the proposed kinetic package).

UPDATE: actually I got the message “Failed to run "xdg-screensaver lock". Ensure you have a locker/screensaver compatible with xdg-screensaver installed and running” again. But the system successfully suspends.

Also, on the lock screen I get different messages now: “not launching hack (throttled.)” and “LOCK ClientMessage received while already locked”.

(Actually I realise these were the original messages in the bug, but I was getting other messages before, sorry for confusion)

[thedoctar (thedoctar)]

I tried installing xscreensaver 6.02 from debian unstable, but when I did, I got the problem again, where the screen is locked before suspending... and when I downgraded the problem persisted. Very weird!

It seems that systemctl and xscreensaver are not playing nice together. Disabling “lock screen after X minutes” seems to fix the issue.

[thedoctar (thedoctar)]

So here's the problem: if you have “lock screen after X minutes” enabled in xscreensaver, and you run `systemctl suspend`, then for some reason systemd first LOCKS the screen, which stops the suspend; only after unlocking the screen does the system suspend.

If you uncheck “lock screen after X minutes”, then systemctl suspend FIRST suspends THEN locks.

Very strange behaviour!!

[thedoctar (thedoctar)]

Okay, here's an EVER WEIRDER UPDATE!

The interactions between xscreensaver and systemd are determined by xscreensaver-systemd.

So I killed xscreensaver-systemd and then ran xscreensaver-systemd -verbose to look at the terminal output.

AND I COULDN'T REPRODUCE THE BUG!!!

Having “lock screen after X minutes” enabled led to a normal suspension of the system, and NO MORE ERROR MESSAGES after a while.
----
xscreensaver-systemd: 22:18:44: connected
xscreensaver-systemd: 22:18:50: exec: xscreensaver-command -verbose -suspend
xscreensaver-command: ClientMessage ignored while authentication dialog is active

xscreensaver-systemd: 22:18:51: exec: "xscreensaver-command -verbose -suspend" exited with status 255
xscreensaver-systemd: 22:18:54: exec: xscreensaver-command -verbose -deactivate
xscreensaver-command: ClientMessage ignored while authentication dialog is active

xscreensaver-systemd: 22:18:54: exec: "xscreensaver-command -verbose -deactivate" exited with status 255
xscreensaver-systemd: 22:19:24: exec: xscreensaver-command -verbose -suspend
xscreensaver-command: suspending.

xscreensaver-systemd: 22:19:29: exec: xscreensaver-command -verbose -deactivate
xscreensaver-command: deactivating.

xscreensaver-systemd: 22:19:54: exec: xscreensaver-command -verbose -suspend
xscreensaver-command: suspending.

xscreensaver-systemd: 22:19:57: exec: xscreensaver-command -verbose -deactivate
xscreensaver-command: deactivating.

[thedoctar (thedoctar)]

So I just restarted my system, and I got the bug.

BUT, when I killed and reran xscreensaver-systemd, THE BUG DISAPPEARED.

This seems to indicate that xscreensaver-systemd is being run too early in the login/startup process.

[thedoctar (thedoctar)]

Sorry, I thought xscreensaver-systemd would have been started by systemd, because it was in the name, but I'm certain now it's started by lxqt-session, as correctly determined by the original reporter.

[thedoctar (thedoctar)]

Okay, now I'm getting *REALLY* weird results. Basically, if I tick “lock after X minutes” and restart xscreensaver-systemd from a script, the bug *PERSISTS*. BUT, if I kill and restart the daemon by hand in a terminal, the problem goes away. So weird!

The message “LOCK CLientMessage received while already [locked]” simply refers to the notifications in the lxqt desktop, probably about connecting/disconnecting wifi.

“not launching hack” means that there won't be a screensaver loaded; for some reason jwz called them hacks.

So it seems to me that there is a clash between the xscreensaver daemon and what lxqt is trying to do. I'm guessing killing and restarting the daemon by hand somehow kills some of the features of the xscreensaver daemon that clash with the lxqt system.

Also, if I simply kill the xscreensaver daemon, my screen is still locked after suspend.

Also I'm using the latest v1.1.1 of lxqt-session.

[Aaron Rainbolt (arraybolt3)]

I don't know if my configuration is a little wonky or what (I don't think XScreenSaver's configuration file is even able to be the problem here), but I'm intermittently getting this problem on my Lubuntu 23.04 laptop, which is set to lock the screen when I close the lid. (I purposefully am not making it suspend). Most of the time it works, but sometimes I'll open the lid and the error message about xdg-screensaver lock will be there, with my screen unlocked.

[thedoctar (thedoctar)]

My guess is that lxqt-session is not interfacing with xscreensaver correctly. Maybe this is related?: https://github.com/lxqt/lxqt-session/issues/274