XScreensaver does not trigger reliably before suspend-to-ram

[DTMW2]

Qubes OS version:

Qubes release 4.0 (R4.0) with all updates installed (2018/03/08)

• had this problem several times with 3.2 in 2017

Affected component(s):

X11 -> XScreensaver (qubes as a whole system because screen lock does not get activated reliably)

---

Steps to reproduce the behavior:

Sporadic misbehavior; not able to reproduce it systematically. I use the wonderful Qubes for quite a time now. And both with 3.2 on a thinkpad X230 and with 4.0 on a thinkpad X1Carbon 5th Gen. every now and then (say once every two month with daily use) after cklicking on suspend in Xfce-logout the system won't supend immediately but stay active/unchanged for some looong seconds. Some seconds later XScreensaver gets activated and the system is still active! Then it is possible to deactivate XScreensaver and suddenly the system changes to suspend-to-ram. These constellations lead to a situation where the system changes to suspend without screen lock and after resuming the system everyone can access it without a password.

Expected behavior:

No race-condition(?) / reliable and immediate change to suspend to ram after clicking "suspend"

Actual behavior:

System is not locked in a failsafe manner.

General notes:

---

Related issues:

[marmarek]

The screenlocker (xscrensaver in this case) is specifically activated before sleep to avoid race-condition on resume. If you unlock it in that short window, well, you've done it yourself. And you you know in that case that the system is unlocked (because you unlocked it yourself). Activating the screenlocker any later could lead to a race condition when it isn't properly locked a moment after resume. The problem here is, sometimes the suspend takes more time. In most cases it is related to misbehaving drivers in sys-usb/sys-net, which needs to be properly suspended first - otherwise you'll be left with unusable/crashed sys-net/sys-usb after resume. There is nothing we can really do here, we don't have capacity to debug drivers for all kind of devices. So, the solution here is: when you suspend the system, do not unlock the screen when it gets locked. But if you do it anyway, then wakeup the system and suspend again.

[marmarek]

The screenlocker (xscrensaver in this case) is specifically activated before sleep to avoid race-condition on resume. If you unlock it in that short window, well, you've done it yourself. And you you know in that case that the system is unlocked (because you unlocked it yourself). Activating the screenlocker any later could lead to a race condition when it isn't properly locked a moment after resume. The problem here is, sometimes the suspend takes more time. In most cases it is related to misbehaving drivers in sys-usb/sys-net, which needs to be properly suspended first - otherwise you'll be left with unusable/crashed sys-net/sys-usb after resume. There is nothing we can really do here, we don't have capacity to debug drivers for all kind of devices. So, the solution here is: when you suspend the system, do not unlock the screen when it gets locked. But if you do it anyway, then wakeup the system and suspend again.

[DTMW2]

Thanks for your excellent technical explanation! The danger probably lies in: waiting, waiting, waiting, ah lets see what's wrong with the system and unlock the screen, then sudden supend-to-ram, "oh, perfect, that is what i wanted" ... ;-) perhaps novice/non-IT-users could misinterpret that.

but I understand the technical and general difficulty.

[DTMW2]

Thanks for your excellent technical explanation! The danger probably lies in: waiting, waiting, waiting, ah lets see what's wrong with the system and unlock the screen, then sudden supend-to-ram, "oh, perfect, that is what i wanted" ... ;-) perhaps novice/non-IT-users could misinterpret that.

but I understand the technical and general difficulty.