Screen lock stuck on suspend

h2 · 2023-11-16 20:04:58

First, thanks to all the XFCE devs who make this great desktop, I'd be lost without it. Much appreciated.

I've been having this issue off and on now for a year or so on my main complicated desktop with many windows, dual monitor, 8 virtual desktops [edit: removed misleading info about 2nd system].

Eventually, something happens (unknown what) which breaks suspend/logout completely, forcing me to just manually force a reboot, or a lightdm restart. This is ok, since it only happens every few months, but it is leaving a hanging lock file or something on the lock suspend action, which then makes 'lock on suspend' return this error via a dialogue:

Failed to suspend session
Failed to lock screen

If I disable lock screen on suspend/hibernate in power manager settings, I can then suspend, and it resumes with the non xfce native unlock dialogue (I can tell it's not the native xfce unlock dialogue because I can't move it between monitors, and it's significantly larger than the normal unlock screen login box. This is how I know there is a stray lock file somewhere or other, but I cannot find where it is so I can delete it.

I can manually force a lock via xflock4

https://forum.xfce.org/viewtopic.php?id=17060

That thread was useful for some debugging options, which may help me locate what is making the initial failure to logout/suspend issue which forces the reboot, which will then often complain about stuck suspend action, forcing sometimes a hard reset, but that varies.

The error event appears when I click the Log Out panel item, then click Suspend, just that error dialogue pops up (because there is apparently already some type of lockscreen lock file present?).

As a work around, I can unselect the power manager settings item to lock screen on suspend, which then lets me suspend ("systemctl suspend" also suspends since it's bypassing the xfce lock screen event), but when it resumes, whatever is stuck makes the unlock login appear, which is different from the normal xfce one, which follows the mouse across monitors, and is smaller than this one.

So there's two questions, first, where is that lock file or suspend file so I can delete it when this happens? I can't find it, I've looked.

Second, and not as related or important, is there a way to diagnose a failure to logout event, which appears to be triggered by some process waiting for something, like an open dialogue, but is not always triggered by that, so I have never been able to find the true cause of the initial failure to suspend/logout, which then forces the hard exit from the session, which then creates the stuck suspend lock file.

xfconf-query -c xfce4-power-manager -lv
/xfce4-power-manager/blank-on-ac                    10
/xfce4-power-manager/dpms-enabled                   false
/xfce4-power-manager/dpms-on-ac-off                 20
/xfce4-power-manager/dpms-on-ac-sleep               15
/xfce4-power-manager/lock-screen-suspend-hibernate  true
/xfce4-power-manager/logind-handle-lid-switch       false
/xfce4-power-manager/power-button-action            3
/xfce4-power-manager/sleep-button-action            1

Note: Has Battery is not true, it's false. Not even a device type battery. That may be a bug.

xfce4-power-manager --dump

(xfce4-power-manager:13131): libnotify-WARNING **: 11:54:39.605: Failed to connect to proxy

(xfce4-power-manager:13131): xfce4-power-manager-WARNING **: 11:54:39.657: could not map keysym 1008ffa8 to keycode

(xfce4-power-manager:13131): xfce4-power-manager-WARNING **: 11:54:39.657: could not map keysym 1008ffa7 to keycode

(xfce4-power-manager:13131): xfce4-power-manager-WARNING **: 11:54:39.657: could not map keysym 1008ff02 to keycode

(xfce4-power-manager:13131): xfce4-power-manager-WARNING **: 11:54:39.657: could not map keysym 1008ff03 to keycode

** (xfce4-power-manager:13131): WARNING **: 11:54:39.668: No outputs have backlight property

(xfce4-power-manager:13131): xfce4-power-manager-WARNING **: 11:54:39.672: Failed to get keyboard max brightness level : GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at path “/org/freedesktop/UPower/KbdBacklight”
---------------------------------------------------
       Xfce power manager version 4.18.2
With policykit support
With network manager support
---------------------------------------------------
Can suspend: True
Can hibernate: True
Authorized to suspend: True
Authorized to hibernate: True
Authorized to shutdown: True
Has battery: True
Has brightness panel: False
Has power button: True
Has hibernate button: False
Has sleep button: True
Has battery button: True
Has LID: False

System:

inxi -SMGxxxz --vs
inxi 3.3.31-00 (2023-11-02)
System:
  Kernel: 6.5.11-4-liquorix-amd64 arch: x86_64 bits: 64 compiler: gcc
    v: 13.2.0 clocksource: tsc Desktop: Xfce v: 4.18.1 tk: Gtk v: 3.24.36
    info: xfce4-panel wm: xfwm v: 4.18.0 vt: 7 dm: 1: LightDM v: 1.32.0
    2: SDDM note: stopped Distro: Debian GNU/Linux trixie/sid
Machine:
  Type: Desktop System: Gigabyte product: X470 AORUS ULTRA GAMING v: N/A
    serial: <superuser required>
  Mobo: Gigabyte model: X470 AORUS ULTRA GAMING-CF
    serial: <superuser required> BIOS: American Megatrends LLC. v: F62d
    date: 10/13/2021
Graphics:
  Device-1: AMD Cedar [Radeon HD 5000/6000/7350/8350 Series] vendor: XFX Pine
    driver: radeon v: kernel arch: TeraScale-2 pcie: speed: 2.5 GT/s lanes: 16
    ports: active: DVI-I-1,VGA-1 empty: HDMI-A-1 bus-ID: 0a:00.0
    chip-ID: 1002:68f9 class-ID: 0300 temp: 51.0 C
  Display: x11 server: X.Org v: 1.21.1.9 with: Xwayland v: 23.2.2
    compositor: xfwm v: 4.18.0 driver: X: loaded: modesetting dri: r600
    gpu: radeon display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 2560x1024 s-dpi: 96 s-size: 677x270mm (26.65x10.63")
    s-diag: 729mm (28.7")
  Monitor-1: DVI-I-1 pos: primary,left model: Samsung SyncMaster
    serial: <filter> res: 1280x1024 hz: 60 dpi: 96
    size: 338x270mm (13.31x10.63") diag: 433mm (17") modes: max: 1280x1024
    min: 720x400
  Monitor-2: VGA-1 pos: right model: Dell 1908FP serial: <filter>
    res: 1280x1024 hz: 60 dpi: 86 size: 376x301mm (14.8x11.85")
    diag: 482mm (19") modes: max: 1280x1024 min: 720x400
  API: EGL v: 1.5 hw: drv: amd r600 platforms: device: 0 drv: r600 device: 1
    drv: swrast gbm: drv: kms_swrast surfaceless: drv: r600 x11: drv: r600
    inactive: wayland
  API: OpenGL v: 4.5 vendor: mesa v: 23.2.1-1 glx-v: 1.4 es-v: 3.1
    direct-render: yes renderer: AMD CEDAR (DRM 2.50.0 /
    6.5.11-4-liquorix-amd64 LLVM 16.0.6) device-ID: 1002:68f9
  API: Vulkan v: 1.3.268 layers: 3 surfaces: xcb,xlib device: 0 type: cpu
    driver: mesa llvmpipe device-ID: 10005:0000

Last edited by h2 (2023-11-16 20:43:46)

h2 · 2023-11-16 20:26:25

In terms of the initial trigger event, the ideal would be to find what is blocking the logout/suspend event, sometimes I can find it by looking through all the open windows and closing suspect ones down, but sometimes I can't find anything, and have to do the hard reboot, or at least ctrl + alt + F1 to console then reboot to force the desktop to shutdown. Which then sticks some file somewhere for screen lock event.

The perfect solution would be to get a way to find out what is blocking the logout event, since if I can find that, the second resultant stuck lock screen file event would I believe never happen. But the perfect doesn't have to be found since the 'good enough' solution is to just know which file to delete that blocks xfce suspend lock screen event.

Last edited by h2 (2023-11-16 20:31:31)

ToZ · 2023-11-16 23:50:28

Hello and welcome.

You don't mention the distro you use, so the process may be different, but look at the system logs (journalctl on systemd-based systems). There may be some additional information there.

I would also check to see if something is specifically inhibiting the system - the easiest way would be to left-click the power icon on the panel - it would list any inhibitors.

You might also consider running xfce4-power-manager in debug mode:

xfce4-power-manager -Q && xfce4-power-manager --no-daemon --debug

...as well as xfce4-session in debug mode. For xfce4-session, export a system-wide environment variable:

XFSM_VERBOSE=1

... and restart your system. On the next login you should have an ~/.xfce4-session.verbose-log file that xfce4-session will log to.

Which screensaver/lock program are you using or is running?

ps -ef | grep -E 'screen|lock'

If xflock4 works, then you also might have a dbus issue with your system. Knowing the distro and how you start Xfce would be helpful. If it is systemd based. the following output after the issue is encountered might yield some information:

journactl --user -b 0 --no-pager

h2 · 2023-11-17 00:10:56

Sorry, I forgot to note the screensaver, which I don't remember ever consciously setting, but:

ps -ef | grep -E 'screen|lock'
...
...gnome-screensaver

Distro is in the inxi: Debian testing (trixi/sid)

Not sure where the power icon is, I don't think I have that present. I will have to find that, that seems like it might be the solution to the initial inhibitor issue, which is actually what causes the second issue with the stuck lock file issue. I tried adding the power manager plugin to a panel but that doesn't really have any information like what you suggested, it's just an icon that offers views of settings and some other things.

I had checked journalctl but because I don't believe this is a system issue, it's simply the xfce lock screen on suspend encountering some type of lock action that is stuck from the failed logout or suspend event (usually the failure is failure to suspend, sorry, I forgot that part of the symptoms, when I click suspend, the desktop usually will suspend, but the system doesn't go into full suspend mode, computer is still partially 'on', then if I push power button, it wakes from suspend, until I give up, and have to force the reboot to clear whatever is stuck. I've never found any journalctl issues logged for that however, so I have no idea what causes that initial failure, that may not be related to xfce is my suspicion.

It's possible my desktop data simply gets too big and can't get packed into the RAM in time, thus forcing the odd half suspend state, which I forgot to note in my iniitial post since it had slipped my mind. But given I have 32 GiB RAM and rarely use more than 1/2 of it it's unlikely that's the issue, but it may be outside of xfce scope, I think it's a more core issue maybe.

I'm debating switching to i3lock if that works with xfce4 if I can't resolve this particular issue.

All the behaviors point to a stuck lockfile type issue when xfce4 logout item is used to select suspend, it surprised me that xflock4 actually worked when the gui suspend + lock fails since I would have thought the xfce logout dialogue is just tripping xflock4 then suspend?

The initial suspend or logout issues may or may not be xfce caused, but the final xfce gui logout suspend failure due to lock action already being engaged (or so it believes) is definitely an xfce issue.

I suspect this is not a common situation because I have been unable to ever find any issue or bug report that seems to duplicate this (since it won't happen unless you force the session to hard exit via reboot on CLI, or hard reset, which suggests something doesn't get cleared.)

The last time this happened I did a big system upgrade and that cleared whatever was stuck, but now it's stuck again, which is irksome.

Note that I can do the suspend fine as long as I disable lock screen on suspend, which then triggers the actual stuck lock/wake item as far as I can tell, so the result is even though it's not supposed to be locking the screen, the stuck lock command or file still forces the unlock login to appear, but that's something of a cludge and workaround which doesn't actually address the underlying issue.

Basically what I can't figure out is what the xfce suspend button is looking for when the switch for lock on suspend is enabled, whatever that is, is what is stuck I believe. The failure is pretty clearly the lock screen command encountering something that tells it that is already happening, at which points it pops up the message saying it can't do it because it's already happening.

Last edited by h2 (2023-11-17 00:23:16)

ToZ · 2023-11-17 00:49:57

h2 wrote:

Not sure where the power icon is, I don't think I have that present. I will have to find that, that seems like it might be the solution to the initial inhibitor issue, which is actually what causes the second issue with the stuck lock file issue. I tried adding the power manager plugin to a panel but that doesn't really have any information like what you suggested, it's just an icon that offers views of settings and some other things.

Yes, it is the power manager plugin. If something is inhibiting power management, you would see something like this when you left click the icon:

I'm debating switching to i3lock if that works with xfce4 if I can't resolve this particular issue.

Maybe also consider xfce4-screensaver - its the Xfce screensaver app.

All the behaviors point to a stuck lockfile type issue when xfce4 logout item is used to select suspend, it surprised me that xflock4 actually worked when the gui suspend + lock fails since I would have thought the xfce logout dialogue is just tripping xflock4 then suspend?

xflock4 uses a different mechanism to lock than the menu suspend feature. xflock4 is a shell script so you can review what it does. The menu uses dbus calls.

The initial suspend or logout issues may or may not be xfce caused, but the final xfce gui logout suspend failure due to lock action already being engaged (or so it believes) is definitely an xfce issue.

I think what is happening is that Xfce is makign a dbus call here and its failing. Thats why I was wondering if there was something logged about it - related to dbus.

Note that I can do the suspend fine as long as I disable lock screen on suspend, which then triggers the actual stuck lock/wake item as far as I can tell, so the result is even though it's not supposed to be locking the screen, the stuck lock command or file still forces the unlock login to appear, but that's something of a cludge and workaround which doesn't actually address the underlying issue.

Yes this is odd.

Basically what I can't figure out is what the xfce suspend button is looking for when the switch for lock on suspend is enabled, whatever that is, is what is stuck I believe. The failure is pretty clearly the lock screen command encountering something that tells it that is already happening, at which points it pops up the message saying it can't do it because it's already happening.

Hopefully you'll have a change to run xfce4-power-manager and xfce4-session with debug logs enabled so we can get some insight into what is happening.

Here are a couple of recent closed related bug reports. Have a read through to see if this is what you are experiencing:
- https://gitlab.xfce.org/xfce/xfce4-session/-/issues/127
- https://gitlab.xfce.org/xfce/xfce4-session/-/issues/163
There may be some info/clues there that would be useful.

h2 · 2023-11-17 01:19:16

I'll start going through this list, thanks.

The power manager plugin may help fix at least part of the first set of events, so that's a good one.

I have no idea why I'm running gnome-screensaver, it was certainly not a choice I made consciously since I'd always preference xfce native over gnome or kde anything, so I'll strip that out and see if any behavior alters. It must be some cruft leftover from when I was testing gnome ages ago. I'll check this a bit now with the proper xfce4-screensaver and see.

Because this event is completely unpredictable, and can takes months to manifest (though the more heavy programs I have running, like audacity instances, vbox guests, etc, the more likely it starts to get re the initial failure)

Thanks for clarifying the xflock4 vs dbus, that helps at least focus the issue.

I've run xfce4-power-manager in debug mode to see if anything appears when the failure to suspend issue due to stuck lock event occurs but I did not see anything resembling warnings or alerts or errors in the output.

I'll check the bug reports, thanks.

My feeling is this may be several issues, so I'll try to narrow it down for each symptom and see.

Last edited by h2 (2023-11-17 01:20:32)

h2 · 2023-11-17 02:19:16

These are hard things to debug since it is intermittent. Replaced with xfce4-screensaver then forgot to restart something so had to restart lightdm because had no login, my fault, hard to remember all the details to do.

After logging in again, the stuck thing is gone, but that's why I have not been able to track this down, something random happens and suddenly it works.

But using native xfce4-screensaver was a good suggestion because it will reduce the variables and make it more predictable.

https://gitlab.xfce.org/xfce/xfce4-session/-/issues/127 that is essentially my issue except mine did not have a deliberately custom set screen locker, but now I wonder if it's a similar issue because mine was using I assume gnome-screensaver? Hard to know, I purged gnome-screensaver from system to get rid of that variable. But it's barely or faintly possible that using a non native screenlocker/saver may be related.

Both of those issues seem similar however, though mine has added compexity due to the initial cause of suspend itself only partially working, which I do not feel is an xfce issue, but it may trigger the following behaviors.

Looking in: journalctl --no-pager -r
see a lot of weird gvfsd events but those come from mtp issues and my phone.

then these which are in fact gnome-screen saver:

Nov 16 11:10:00 box gnome-screensaver-dialog[11911]: PAM adding faulty module: pam_gnome_keyring.so
Nov 16 11:10:00 box gnome-screensaver-dialog[11911]: PAM unable to dlopen(pam_gnome_keyring.so): /lib/security/pam_gnome_keyring.so: cannot open shared object file: No such file or directory
Nov 16 11:07:56 box gnome-screensaver-dialog[11762]: PAM adding faulty module: pam_gnome_keyring.so
Nov 16 11:07:56 box gnome-screensaver-dialog[11762]: PAM unable to dlopen(pam_gnome_keyring.so): /lib/security/pam_gnome_keyring.so: cannot open shared object file: No such file or directory
Nov 16 11:06:18 box gnome-screensaver-dialog[11448]: PAM adding faulty module: pam_gnome_keyring.so
Nov 16 11:06:18 box gnome-screensaver-dialog[11448]: PAM unable to dlopen(pam_gnome_keyring.so): /lib/security/pam_gnome_keyring.so: cannot open shared object file: No such file or directory
Nov 16 11:03:05 box dbus-daemon[1619]: [session uid=1000 pid=1619] Successfully activated service 'org.xfce.Xfconf'
Nov 16 11:03:05 box dbus-daemon[1619]: [session uid=1000 pid=1619] Activating service name='org.xfce.Xfconf' requested by ':1.120' (uid=1000 pid=2229 comm="xfce4-terminal --geometry=125x40 --display :0.0 --")
Nov 16 10:55:08 box dbus-daemon[1619]: [session uid=1000 pid=1619] Successfully activated service 'org.xfce.Xfconf'
Nov 16 10:55:08 box dbus-daemon[1619]: [session uid=1000 pid=1619] Activating service name='org.xfce.Xfconf' requested by ':1.105' (uid=1000 pid=2148 comm="xfce4-panel --display :0.0 --sm-client-id 2cab34ec")
Nov 16 10:46:40 box gnome-screensaver-dialog[10766]: PAM adding faulty module: pam_gnome_keyring.so
Nov 16 10:46:40 box gnome-screensaver-dialog[10766]: PAM unable to dlopen(pam_gnome_keyring.so): /lib/security/pam_gnome_keyring.so: cannot open shared object file: No such file or directory
Nov 15 23:33:18 box dbus-daemon[1619]: [session uid=1000 pid=1619] Successfully activated service 'org.xfce.Xfconf'
Nov 15 23:33:18 box dbus-daemon[1619]: [session uid=1000 pid=1619] Activating service name='org.xfce.Xfconf' requested by ':1.115' (uid=1000 pid=2204 comm="/usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-2.0")

However xscreensaver has similar error on the lightdm restart.

Then there are these, using sudo journalctl :

Nov 16 17:23:51 box systemd[1]: Stopping session-c2.scope - Session c2 of User lightdm...
Nov 16 17:23:51 box lightdm[17974]: pam_unix(lightdm-greeter:session): session closed for user lightdm
Nov 16 17:23:51 box lightdm[17974]: pam_unix(lightdm-greeter:session): session closed for user lightdm
Nov 16 17:23:51 box lightdm[17974]: pam_systemd(lightdm-greeter:session): Failed to release session: Transport endpoint is not connected
Nov 16 17:23:51 box systemd[1]: session-c2.scope: Deactivated successfully.
Nov 16 17:23:51 box systemd[1]: Stopped session-c2.scope - Session c2 of User lightdm.

Nov 16 17:24:59 box systemd[1]: /etc/systemd/system/suspend.service:6: Invalid user/group name or numeric ID: 
Nov 16 17:24:59 box systemd[1]: suspend.service: Unit configuration has fatal error, unit will not be started.
Nov 16 17:24:59 box systemd[1]: /etc/systemd/system/suspend.service:6: Invalid user/group name or numeric ID: 
Nov 16 17:24:59 box systemd[1]: suspend.service: Unit configuration has fatal error, unit will not be started.
Nov 16 17:24:59 box systemd[1]: /etc/systemd/system/suspend.service:6: Invalid user/group name or numeric ID: 
Nov 16 17:24:59 box systemd[1]: suspend.service: Unit configuration has fatal error, unit will not be started.
Nov 16 17:25:01 box systemd-logind[1187]: The system will suspend now!
Nov 16 17:25:01 box systemd[1]: /etc/systemd/system/suspend.service:6: Invalid user/group name or numeric ID: 
Nov 16 17:25:01 box systemd[1]: suspend.service: Unit configuration has fatal error, unit will not be started.
Nov 16 17:25:01 box CRON[19531]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Nov 16 17:25:01 box CRON[19535]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Nov 16 17:25:01 box CRON[19531]: pam_unix(cron:session): session closed for user root
Nov 16 17:25:04 box kernel: serial8250 serial8250: LSR safety check engaged!
Nov 16 17:25:05 box kernel: serial8250 serial8250: LSR safety check engaged!
Nov 16 17:25:06 box kernel: serial8250 serial8250: LSR safety check engaged!
Nov 16 17:25:06 box systemd-logind[1187]: Delay lock is active (UID 1000/harald, PID 19389/light-locker) but inhibitor timeout is reached.
Nov 16 17:25:06 box systemd[1]: /etc/systemd/system/suspend.service:6: Invalid user/group name or numeric ID: 
Nov 16 17:25:06 box systemd[1]: suspend.service: Unit configuration has fatal error, unit will not be started.
Nov 16 17:25:06 box systemd[1]: suspend.service: Cannot add dependency job, ignoring: Unit suspend.service has a bad unit file setting.
Nov 16 17:25:06 box systemd[1]: Reached target sleep.target - Sleep.

The last set is not helpful since actually "systemctl suspend" works fine, which means the logged message is probably caused by something else.

Last edited by h2 (2023-11-17 02:25:21)

ToZ · 2023-11-17 11:23:42

Nov 16 17:25:06 box systemd-logind[1187]: Delay lock is active (UID 1000/harald, PID 19389/light-locker) but inhibitor timeout is reached.

I notice that light-locker is referenced in that last set of log entries. It is known to conflict with other screensaver apps. Do you have light-locker installed and running? The earlier command you ran showed only gnome-screensaver. Odd that it's showing in the logs though.

Nov 16 17:24:59 box systemd[1]: /etc/systemd/system/suspend.service:6: Invalid user/group name or numeric ID:
Nov 16 17:24:59 box systemd[1]: suspend.service: Unit configuration has fatal error, unit will not be started.

This is also interesting to me. Bad service files tend to muck stuff up. What is the contents of the /etc/systemd/system/suspend.service file? Is this a custom service file that you created?

h2 · 2023-11-17 20:35:31

systemd suspend
I've never touched the service file, that error is a bug, probably in systemd itself is my guess.

cat /etc/systemd/system/suspend.service
[Unit]
Description=User suspend actions
Before=sleep.target

[Service]
User=%I
Type=forking
Environment=DISPLAY=:0
ExecStart=/lib/systemd/system-sleep/45fix-usb-wakup pre suspend
ExecStartPost=/usr/bin/sleep 1

[Install]
WantedBy=sleep.target

I'd call that a classic red herring, systemd does something wrong internally when confronted with some event or other, then maps it to the wrong error message. Fairly typical for the internal shoddiness of systemd, which is hopefully getting cleared up slowly. So yes, systemd probably did hit some event, but the internal logging assigned it to the wrong error message. I'm sure systemd has tons of that stuff internally, which will probably take many more years to correct and clear out. As an aside, I started using suspend specifically because systemd failed so consistently to shutdown or boot, so I figured, if I switch to suspend, at least my system will be running between actual boots/shutdowns. That state has improved a lot, now I tend to have successful boots, but that took about 10 years to achieve for systemd.

That's probably not possible to diagnose or debug further since it's the wrong message, which appears to have been triggered by some other events. Normally suspend works fine, and in fact, systemd suspend always worked via cli when the dbus locked suspend issue in xfce manifested. Not always in other cases where it's even more confused re too many suspend events though. But always when the gui gave that lock error dialogue, then I'd just use cli systemd suspend instead, until I realized that if I disabled lock on suspend in xfce power manager, then the stuck lock event would activate on resume, with the non normal xfce dialogue login box.

light-locker
light-locker is installed. I think I see that sometimes flash by on the way to the actual xfce unlock dialogue, but it's too fast to really catch, it's just a flash before the normal wake / resume login window appears.

From 2023-06 system debugger dataset, which was the pre issue setup exactly, gnome-screensaver was running, and light-locker was NOT running.

I did no actions to alter this, so it's fairly safe to say that light-locker only started to run when I removed gnome-screensaver and installed xfce4-screensaver. That would explain why I did not see it above. Further double checking, this was also run in X.org, non sudo/root, so this was in X.org Xfce, basically the same setup minus one major upgrade last month to current Debian Testing.

Desktop: Xfce v: 4.18.1 tk: Gtk v: 3.24.36 info: xfce4-panel wm: xfwm v: 4.18.0 vt: 7 
  dm: LightDM v: 1.26.0 Distro: Debian GNU/Linux 12 (bookworm)

So yes, light-locker does not appear to have been running, though it was installed, prior to my installing xfce4-screensaver and removing gnome-screensaver. light-locker is now running, with xfce4-screensaver. I'm not clear on the relationship between xfce4-screensaver and the locker however. This is a new scenario so I can't say if it has any issues since it's only been operational now maybe 18 hours so far.

Useful to avoid red herrings probably, so light-locker seems to not be relevant to the initial set of issues, though the light-locker program was probably installed, it was not running as a service.

This does explain something I'd forgotten, that fast flash of another lock dialogue right before the xfce main login screen appears from wake/ resume. How these things interact is fairly opaque to me however, it's not something I've ever looked into, but I can see why this system has all that stuff running, it's my main dev box and I have tested a lot of desktops on it over the years, which certainly leaves a lot of stuff around. In a sense, a good bug catcher in some ways for unhandled events.

It was I think my impression that light-locker was the lock / unlock tool that controlled screen locking, and xscreen-saver the screen saver, which then offers to lock/unlock the screen, which I think I assumed was done by the locker tool.

Possible XFCE Enhancements?
So if xfce4-screensaver is installed, no other screensavers or screen lockers should be installed? I can see the difficulty however re which settings item to use, when I have checked, I look in Display, which seems logical to me, power manager, which seems fairly logical, then xfce4-screensaver now, which does not seem logical since it's not a generic feature like display or appearance or power management, and only appeared as a setting when I installed xfce4-screensaver, which was not installed previously.

This may suggest a possible xfce enhancement, which is listing the available lock/screensavers in the system, and more important, the ones that are running. I don't remember seeing any such items when I was looking through the settings to try to find something or other, which is why I didn't think to ask myself if multiple screensavers and lockers were present.

Maybe this is a possible way to approach the issue, but again, it's not easy. In inxi, there are current valid issues for data that I am not implementing because I cannot think of a good place to put them, but it seems like as an end user, I had to do a lot of guessing to find these settings, and they are not all in the same place. Tricky, again, and understandable, but maybe worth some thought long term? The only thing I can say for sure is that having the same type of control in two different settings items is confusing and hard to understand, and hard to locate or guess at. But I can't offer any suggestions because it's complicated, beyond maybe repeating the settings in two areas if they match both, say Display and Power Management, or something like that.

This might be worth looking at in terms of what the settings for this reports, since it's not very intuitive to think of what needs to be checked etc for end users I suspect. I was actually surprised not to find such a dedicated lock/screensaver control item, I believe that is distributed in power manager and the dedicated xfce-screensaver settings item, which also somewhat confusingly has similar options to lock on suspend/hibernate that power manager has.

I find these types of decisions to be some of the most difficult I encounter. To me, the primary setting container for screensaver would be Display, with options to lock screen there, as well as in suspend/resume settings in power manager. And ideally one setting area for primary lock/screensaver, that detects the running/installed stuff, though installed is a pain given how paths and names change cross distro.

Solid Items for debugging / solving issues
I was hoping to generate at least a reasonably helpful how to debug post by creating this posting, but this is fairly complicated I think so it's hard to do a bullet point: check x y z for this case.

So far to summarize,, but still to test, is the power icon click event to find logout / suspend inhibitors, that one is possibly one of the true solutions to the subsequent set of issues, or at least, a subset of them.

Unknown relationship between screensavers and lockers, but probably safest to have only 1 installed and running, unless the screensaver requires a dedicated locker tool. Possible conflicts or issues using certain screensavers or lockers but given how totally random these events are (usually take at least 1 month of suspend/resume events before they happen) very hard to say anything at all conclusively beyond seeing if running xfce4-screensaver with light-locker creates any issues over next 45 or so days.

Last edited by h2 (2023-11-17 21:07:12)

h2 · 2023-11-17 21:14:37

I may look into adding an inxi System report item to the WM/Desktop report area to show running screensavers and lockers, but I honestly thought that those were not services, but just programs you triggered when requested. I guess screensavers are services that run since they are always waiting to activate, but lockers I thought were just a program that triggered when something asked the screen to lock or unlock.

ToZ · 2023-11-17 22:30:11

h2 wrote:

systemd suspend
I've never touched the service file, that error is a bug, probably in systemd itself is my guess.

cat /etc/systemd/system/suspend.service
[Unit]
Description=User suspend actions
Before=sleep.target

[Service]
User=%I
Type=forking
Environment=DISPLAY=:0
ExecStart=/lib/systemd/system-sleep/45fix-usb-wakup pre suspend
ExecStartPost=/usr/bin/sleep 1

[Install]
WantedBy=sleep.target

This really looks like a custom add to a system. I have a bookworm VM and it doesn't exist there. Since its crashing on the "User=%I" line and not finishing, I would suggest removing it. Its not doing anything anyway but logging errors. But I agree, probably a red herring.

light-locker
light-locker is installed.

This does explain something I'd forgotten, that fast flash of another lock dialogue right before the xfce main login screen appears from wake/ resume.

light-locker is the lightdm lock screen utility and it will interfere with other screensavers. You are witnessing the interference when you see the the flashing of another login dialog. You can either use light-locker or another screensaver. I would highly recommend uninstalling the one you don't want so there is no potential for conflict.

Possible XFCE Enhancements?
So if xfce4-screensaver is installed, no other screensavers or screen lockers should be installed?

Correct.

This may suggest a possible xfce enhancement, which is listing the available lock/screensavers in the system, and more important, the ones that are running. I don't remember seeing any such items when I was looking through the settings to try to find something or other, which is why I didn't think to ask myself if multiple screensavers and lockers were present.
Maybe this is a possible way to approach the issue, but again, it's not easy. In inxi, there are current valid issues for data that I am not implementing because I cannot think of a good place to put them, but it seems like as an end user, I had to do a lot of guessing to find these settings, and they are not all in the same place. Tricky, again, and understandable, but maybe worth some thought long term? The only thing I can say for sure is that having the same type of control in two different settings items is confusing and hard to understand, and hard to locate or guess at. But I can't offer any suggestions because it's complicated, beyond maybe repeating the settings in two areas if they match both, say Display and Power Management, or something like that.
This might be worth looking at in terms of what the settings for this reports, since it's not very intuitive to think of what needs to be checked etc for end users I suspect. I was actually surprised not to find such a dedicated lock/screensaver control item, I believe that is distributed in power manager and the dedicated xfce-screensaver settings item, which also somewhat confusingly has similar options to lock on suspend/hibernate that power manager has.
I find these types of decisions to be some of the most difficult I encounter. To me, the primary setting container for screensaver would be Display, with options to lock screen there, as well as in suspend/resume settings in power manager. And ideally one setting area for primary lock/screensaver, that detects the running/installed stuff, though installed is a pain given how paths and names change cross distro.

You bring up some interesting discussion points and issues. I agree its somewhat confusing. I would suggest creating an enhancement request at https://gitlab.xfce.org/xfce/xfce4-settings/-/issues if you would like the developers to consider this.

Solid Items for debugging / solving issues
I was hoping to generate at least a reasonably helpful how to debug post by creating this posting, but this is fairly complicated I think so it's hard to do a bullet point: check x y z for this case.
So far to summarize,, but still to test, is the power icon click event to find logout / suspend inhibitors, that one is possibly one of the true solutions to the subsequent set of issues, or at least, a subset of them.
Unknown relationship between screensavers and lockers, but probably safest to have only 1 installed and running, unless the screensaver requires a dedicated locker tool. Possible conflicts or issues using certain screensavers or lockers but given how totally random these events are (usually take at least 1 month of suspend/resume events before they happen) very hard to say anything at all conclusively beyond seeing if running xfce4-screensaver with light-locker creates any issues over next 45 or so days.

Try simplifying the system. Start with just one screensaver/locker program installed. Consider the debug options above - especially the xfce4-session one as its a one time change that will create an ongoing log that you can refer to if and when the issue arises.

h2 · 2023-11-23 00:03:50

I've added the Power suspend/hibernate and screensaver / locker to inxi. When inxi fails to show me something that was / is directly relevant to an issue I am/was having, I tend to add it if it's practical, and since I already had the power state feature request waiting to be done, I figured, this is a good time to do it.

I'll check to see if I have a gitlab account, though I just moved all my stuff to codeberg to avoid the corporate issues of places like github.

pinxi -SI --za
System:
  Kernel: 6.5.11-4-liquorix-amd64 arch: x86_64 bits: 64
  Desktop: Xfce v: 4.18.1 Distro: Debian GNU/Linux trixie/sid
Info:
  Memory: total: N/A available: 31.27 GiB used: 13.71 GiB (43.8%)
  Processes: 750 Uptime: 7d 8m Shell: Bash pinxi: 3.3.31-15
pinxi -SIx --za
System:
  Kernel: 6.5.11-4-liquorix-amd64 arch: x86_64 bits: 64 compiler: gcc
    v: 13.2.0
  Desktop: Xfce v: 4.18.1 Distro: Debian GNU/Linux trixie/sid
Info:
  Memory: total: N/A available: 31.27 GiB used: 13.71 GiB (43.9%)
  Processes: 750 Uptime: 7d 8m Init: systemd target: graphical (5)
  Packages: 3926 Compilers: gcc: 13.2.0 Shell: Bash v: 5.2.15
    pinxi: 3.3.31-15
pinxi -SIxx --za
System:
  Kernel: 6.5.11-4-liquorix-amd64 arch: x86_64 bits: 64 compiler: gcc
    v: 13.2.0
  Desktop: Xfce v: 4.18.1 tk: Gtk v: 3.24.36 wm: xfwm dm: 1: LightDM 2: SDDM
    note: stopped Distro: Debian GNU/Linux trixie/sid
Info:
  Memory: total: N/A available: 31.27 GiB used: 13.72 GiB (43.9%)
  Processes: 750 Power: uptime: 7d 8m wakeups: 15 Init: systemd v: 254
    target: graphical (5) default: graphical
  Packages: pm: dpkg pkgs: 3926 Compilers: gcc: 13.2.0
    alt: 10/11/12/13/5/6/8/9 Shell: Bash v: 5.2.15 running-in: xfce4-terminal
    pinxi: 3.3.31-15
pinxi -SIxxx --za
System:
  Kernel: 6.5.11-4-liquorix-amd64 arch: x86_64 bits: 64 compiler: gcc
    v: 13.2.0 clocksource: tsc
  Desktop: Xfce v: 4.18.1 tk: Gtk v: 3.24.36 info: xfce4-panel wm: xfwm
    v: 4.18.0 vt: 7 tools: light-locker,xfce4-screensaver dm: 1: LightDM
    v: 1.32.0 2: SDDM note: stopped Distro: Debian GNU/Linux trixie/sid
Info:
  Memory: total: N/A available: 31.27 GiB used: 13.71 GiB (43.8%)
  Processes: 750 Power: uptime: 7d 8m states: freeze,mem,disk suspend: deep
    wakeups: 15 hibernate: platform Init: systemd v: 254 target: graphical (5)
    default: graphical
  Packages: pm: dpkg pkgs: 3926 Compilers: gcc: 13.2.0
    alt: 10/11/12/13/5/6/8/9 Shell: Bash v: 5.2.15 running-in: xfce4-terminal
    pinxi: 3.3.31-15
pinxi -SIa --za
System:
  Kernel: 6.5.11-4-liquorix-amd64 arch: x86_64 bits: 64 compiler: gcc
    v: 13.2.0 clocksource: tsc available: hpet,acpi_pm parameters: audit=0
    intel_pstate=disable rcupdate.rcu_expedited=1
    BOOT_IMAGE=/boot/vmlinuz-6.5.11-4-liquorix-amd64 root=UUID=<filter> ro
    quiet
  Desktop: Xfce v: 4.18.1 tk: Gtk v: 3.24.36 info: xfce4-panel wm: xfwm
    v: 4.18.0 vt: 7 tools: light-locker,xfce4-screensaver avail: slock dm:
    1: LightDM v: 1.32.0 2: SDDM note: stopped Distro: Debian GNU/Linux
    trixie/sid
Info:
  Memory: total: N/A available: 31.27 GiB used: 13.72 GiB (43.9%)
  Processes: 750 Power: uptime: 7d 8m states: freeze,mem,disk suspend: deep
    avail: s2idle wakeups: 15 hibernate: platform
    avail: shutdown,reboot,suspend,test_resume image: 12.49 GiB Init: systemd
    v: 254 target: graphical (5) default: graphical tool: systemctl
  Packages: pm: dpkg pkgs: 3926 libs: 2153 tools: apt,apt-get,aptitude
    pm: rpm pkgs: 0 Compilers: gcc: 13.2.0 alt: 10/11/12/13/5/6/8/9 Shell: Bash
    v: 5.2.15 running-in: xfce4-terminal pinxi: 3.3.31-15

Xfce Forum

Sub domains

#1 2023-11-16 20:04:58

Screen lock stuck on suspend

#2 2023-11-16 20:26:25

Re: Screen lock stuck on suspend

#3 2023-11-16 23:50:28

Re: Screen lock stuck on suspend

#4 2023-11-17 00:10:56

Re: Screen lock stuck on suspend

#5 2023-11-17 00:49:57

Re: Screen lock stuck on suspend

#6 2023-11-17 01:19:16

Re: Screen lock stuck on suspend

#7 2023-11-17 02:19:16

Re: Screen lock stuck on suspend

#8 2023-11-17 11:23:42

Re: Screen lock stuck on suspend

#9 2023-11-17 20:35:31

Re: Screen lock stuck on suspend

#10 2023-11-17 21:14:37

Re: Screen lock stuck on suspend

#11 2023-11-17 22:30:11

Re: Screen lock stuck on suspend

#12 2023-11-23 00:03:50

Re: Screen lock stuck on suspend

Board footer