Bug 498298

I have had a quick look at UPower, and at least saw the lid toggling:

$ upower --monitor-detail
Monitoring activity from the power daemon. Press Ctrl+C to cancel.
[23:53:54.853]  daemon changed:
  daemon-version:  1.90.3
  on-battery:      no
  lid-is-closed:   yes
  lid-is-present:  yes
  critical-action: HybridSleep

[23:53:57.904]  daemon changed:
  daemon-version:  1.90.3
  on-battery:      no
  lid-is-closed:   no
  lid-is-present:  yes
  critical-action: HybridSleep

[23:54:13.369]  daemon changed:
  daemon-version:  1.90.3
  on-battery:      no
  lid-is-closed:   yes
  lid-is-present:  yes
  critical-action: HybridSleep

The only (somewhat?) relevant info from journalctl (please note my locale is not C, but instead en_GB.UTF-8

Jan 05 23:53:54 d-allen systemd-logind[1370]: Lid closed.
Jan 05 23:53:54 d-allen wpa_supplicant[1592]: wlp3s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-73 noise=9999 txrate=162000
Jan 05 23:53:54 d-allen dbus-daemon[1309]: [system] Activating service name='org.kde.powerdevil.backlighthelper' requested by ':1.414'>
Jan 05 23:53:54 d-allen org.kde.powerdevil.backlighthelper[32352]: Detected locale "C" with character encoding "ANSI_X3.4-1968", which>
                                                                   Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.
                                                                   If this causes problems, reconfigure your locale. See the locale(1)>
                                                                   for more information.
Jan 05 23:53:54 d-allen dbus-daemon[1309]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper'
Jan 05 23:53:57 d-allen systemd-logind[1370]: Lid opened.
Jan 05 23:53:59 d-allen wpa_supplicant[1592]: wlp3s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-59 noise=9999 txrate=121500
Jan 05 23:54:13 d-allen systemd-logind[1370]: Lid closed.
Jan 05 23:54:13 d-allen dbus-daemon[1309]: [system] Activating service name='org.kde.powerdevil.backlighthelper' requested by ':1.414'>
Jan 05 23:54:13 d-allen org.kde.powerdevil.backlighthelper[32397]: Detected locale "C" with character encoding "ANSI_X3.4-1968", which>
                                                                   Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.
                                                                   If this causes problems, reconfigure your locale. See the locale(1)>
                                                                   for more information.
Jan 05 23:54:13 d-allen dbus-daemon[1309]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper'

Do you by any chance recall when this stopped working? Was there a Plasma update, a kernel update, a upower update, or something else?

Sorry, I should have mentioned this.  This used to work.  Unfortunately, I have used this laptop in a 24/7 on configuration in the last months, so it is a little hard to be precise when this stopped working.  It was certainly working last summer, which is an annoyingly large window of updates.  I am on KDE Neon User Edition 24.04.

I am happy to poke a bit, but I am struggling to know where to start.  If anyone knows the different code paths / general ways we get to suspend, and why this works from Sleep in KMenu, but not from the hotkeys and also not from the lock screen, that would be good to know.  Otherwise, I can start digging and maybe enable the right log options / add some printfs in places and recompile the right things.

I have been reading the powerdevil source code a bit.  It seems there are two ways to get to suspend:

* runner actions -> these seem to be talking to logind directly, and I think they are the ones invoked by KMenu and Krunner -> these seem to work
* daemon actions -> these eventually seem to be turned into DBus commands to org.freedesktop.PowerManagement -> these don't work

Manually trying
  $ qdbus org.freedesktop.PowerManagement /org/freedesktop/PowerManagement Suspend
does nothing.

Some more information:
  $  qdbus org.freedesktop.PowerManagement /org/freedesktop/PowerManagement CanSuspend
  true
  $ qdbus org.freedesktop.PowerManagement /org/freedesktop/PowerManagement/Inhibit HasInhibit
  false

This seems to suggest that whatever hangs on the other side of that DBus port is not doing the right thing.  I will keep digging as time permits, hope me logging stuff here is okay.

Ok, if "qdbus org.freedesktop.PowerManagement /org/freedesktop/PowerManagement Suspend" does not work, it seems like the issue is not on our side, and thus we cannot fix it, I'm closing the bug; maybe it would be better to open up open upstream?

That cannot be it, I think.  On the other side of that qdbus is... powerdevil, again.  I have followed the code and on receiving the DBus command, it *should* *eventually* follow the same code path that gets called from the Krunner activity -- which in turn still works.  I have a suspicion that somewhere between receiving the DBus message and getting it out to logind something breaks.

There seem to be a few layers of wrapping logic here.  I would like to get some debug symbols and attach GDB to the powerdevil process and then do the two approaches again: clicking Sleep in KMenu which works, and then sending the DBus message.  I should also check that closing the lid and the hotkey actually send the DBus message, too.

Or are you saying powerdevil is upstream of plasmashell?

In any case.. I am happy to have this assigned to me for now.

A small amount of update after tracing through powerdevil with GDB (do we really need all these wrappers / adapters /... in there?! another day...).  Reminder, the laptop suspends / suspend-then-hibernate-s fine when doing it via

$ sudo systemctl suspend-then-hibernate

or

$ sudo systemctl suspend

My suspend hotkey does not work and doing a 

$ qdbus org.freedesktop.PowerManagement /org/freedesktop/PowerManagement Suspend

does not work either.  This is a Dbus message to powerdevil.  It gets received correctly, and (after several curious translation steps) eventually calls SessionManagement::suspendThenHibernate (in plasma workspace / libkworkspace) which is what I have configured.

Unfortunately, SessionManagement::canSuspendThenHibernate is false and so nothing happens.

AFAICS, this is a cached version of the value that gets only updated if the backend (logind) updates this value.  The backend is connected via Dbus to org.freedesktop.login1.  I can query the value manually:

$ qdbus --system org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.CanSuspendThenHibernate 
no

$ qdbus --system org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.CanHibernate 
no

which comes as a surprise.  Again.. doing the suspend-then-hibernate with systemctl works.  Unfortunately, I have been unable to dive deeper into why that is the case.  I have followed the code in systemd-logind and set breakpoints on the running process at the interesting functions where it should compute something about hibernation.  But none of the breakpoints trigger.  Also, increasing the log-level of systemd to debug does not show any of the debug messages in the code here.  It is as if the code in systemd-logind is actually never called.

Maybe there is one more layer of caching / proxying going on.

Next step is to check who is actually listening on the Dbus at org.freedesktop.login1.