Manual suspend doesn't work anymore.

[00due]

After updating my system (Arch Linux) a few days ago, manually suspending has stopped working. The button in the control center does nothing, and the power button prompts me to shut down the PC.

Running systemctl hybrid-sleep returns this:
Operation inhibited by "username" (PID 1277 "gnome-session-b", user username), reason is "user session inhibited".

I tried disabling my extensions one by one, and the one causing this is Caffeine. Also, if I just disable Caffeine from the control center, that allows me to suspend too.

[stuarthayhurst]

That AI sure doesn't like }...

If that fixes the problem, it's the flag that controls Inhibit suspending the session or computer that it doesn't like, but dropping that would mean dropping for "Allow screen blank" in our settings.

[PhrozenByte]

I can confirm this issue with Caffeine 55 on GNOME Shell 47.2:

$ systemd-inhibit | grep '\bsleep\b.*\bblock\b'
daniel         1000 daniel 3533 gnome-session-b sleep                                                    user session inhibited                                      block
$ dbus-send --print-reply --dest=org.gnome.SessionManager /org/gnome/SessionManager org.gnome.SessionManager.GetInhibitors
method return time=1735859241.166665 sender=:1.11 -> destination=:1.1295 serial=4381 reply_serial=2
   array [
      object path "/org/gnome/SessionManager/Inhibitor100"
   ]
$ dbus-send --print-reply --dest=org.gnome.SessionManager /org/gnome/SessionManager/Inhibitor100 org.gnome.SessionManager.Inhibitor.GetAppId
method return time=1735859262.451220 sender=:1.11 -> destination=:1.1296 serial=4382 reply_serial=2
   string "user"
$ dbus-send --print-reply --dest=org.gnome.SessionManager /org/gnome/SessionManager/Inhibitor100 org.gnome.SessionManager.Inhibitor.GetReason
method return time=1735859290.189449 sender=:1.11 -> destination=:1.1297 serial=4383 reply_serial=2
   string "Inhibit by Caffeine"

Took me quite some while to figure out that Caffeine is at fault, because it worked before. Disabling Caffeine before attempting to hibernate solves the issue, it's just a little inconvenient to be required to disable Caffeine first.

@stuarthayhurst I truly don't understand your comment. Is it about adding a option to allow for manual hibernation again at the cost of force-disabling the "Allow screen blank" option if enabled? Personally I wouldn't mind, because I use Caffeine precisely to keep the screen active.

Amazing project btw, to all contributors, keep up the great work here ❤️

[stuarthayhurst]

@stuarthayhurst I truly don't understand your comment. Is it about adding a option to allow for manual hibernation again at the cost of force-disabling the "Allow screen blank" option if enabled? Personally I wouldn't mind, because I use Caffeine precisely to keep the screen active.

So when we tell GNOME not to sleep, we get some config on how exactly the shell interprets this. By default, Caffeine tells the shell to not mark to session as idle (a.k.a don't let the screen blank), and also tells it not to suspend the session (a.k.a don't sleep the computer, the most important bit). I was originally replying to someone that used an AI to create a solution that supposedly worked, and in their solution it dropped the part that stops the screen from blanking, which is why I mentioned removing that setting.

My comment probably doesn't make much sense without the context of the comment I was replying to, I guess they deleted it?

However, I never tested that 'fix' because it was full of syntax errors, and I also can't really reproduce this problem myself. A while ago the shutdown button stopped working after a systemd update but that went away with the next update so I didn't investigate it further.

Amazing project btw, to all contributors, keep up the great work here ❤️

❤️

[PhrozenByte]

I was originally replying to someone that used an AI to create a solution that supposedly worked

Ah, I see, this explains my confusion. AFAIK only GitHub Support can remove comments without a trace, so GitHub probably just deleted the whole account if it was some spammy AI account.

So when we tell GNOME not to sleep, we get some config on how exactly the shell interprets this. By default, Caffeine tells the shell to not mark to session as idle (a.k.a don't let the screen blank), and also tells it not to suspend the session (a.k.a don't sleep the computer, the most important bit).

Unfortunately I'm not deep enough into the inner workings of Caffeine. Are you referring to Caffeine's optional (disabled by default) "Allow screen blank: Allow turning off screen when Caffeine is enabled" setting? Because setting this to "Always" doesn't seem to make any difference with inhibiting manual hibernation. Or are you referring to something else?

Did Caffeine change something in this regard lately? Else this might be a regression of Gnome Shell 47.2, or even some other component (maybe systemd?). I'm an Arch Linux user too (like @00due). Arch Linux is pretty close to upstream, we thus see such regressions early. However, I just checked my Pacman logs (Arch's package manager) and there wasn't a Gnome Shell upgrade recently. I upgraded to Gnome Shell 47.2 on 2024-11-28, Gnome Session didn't release a new version since 47.0 (released in Sept). What was upgraded recently was systemd 257.1 on 2024-12-22. I'm not entirely sure when manual hibernation stopped working, but it might have been around that time. @00due, can you narrow that down further? Kinda matches with the day you've created this issue.

If this issue is indeed caused by some other component, it might also explain why you (@stuarthayhurst) can't reproduce it. Are you using older versions of Gnome Shell and/or systemd? Just let us know how we can help you with debugging this issue.

Since disabling Caffeine before hibernating works for now (one just needs to know 😆), we could alternatively also just wait a little longer to check whether the next systemd version fixes this again (like with the shutdown button you mentioned).

[stuarthayhurst]

Unfortunately I'm not deep enough into the inner workings of Caffeine. Are you referring to Caffeine's optional (disabled by default) "Allow screen blank: Allow turning off screen when Caffeine is enabled" setting? Because setting this to "Always" doesn't seem to make any difference with inhibiting manual hibernation. Or are you referring to something else?

Yep, that was the setting I was on about. Thanks for checking that, shame it didn't work :(

Did Caffeine change something in this regard lately? Else this might be a regression of Gnome Shell 47.2, or even some other component (maybe systemd?).

Nope, we mostly release around the same time as new GNOME versions, including whichever miscellaneous bits changed between GNOME releases. It had been fine for me on GNOME 47 for a long time, I only saw a few hiccups around the same time as some systemd updates, and nothing recently.

If this issue is indeed caused by some other component, it might also explain why you can't reproduce it. Are you using older versions of Gnome Shell and/or systemd? Just let us know how we can help you with debugging this issue.

I run Debian Unstable, so my packages should be more or less in line with yours on Arch. Running GNOME Shell 47.2 and SystemD 257.1.

Since disabling Caffeine before hibernating works for now (one just needs to know 😆), we could alternatively also just wait a little longer to check whether the next systemd version fixes this again (like with the shutdown button you mentioned).

Mmm, nothing immediately seems wrong on our end, I wonder if a component changed how it interpreted the specification (i.e. systemd sees an inhibitor and refuses to suspend / hibernate / shut down). When I triggered the bug before, sudo shutdown now gave me a complaint that a user session was inhibited, so this might be the case. If so, we'd need some kind of signal from the system that it wants to shutdown / hibernate manually, and then we'd drop the inhibitors.

It could also be that GNOME started checking inhibitors before disabling extensions, meaning Caffeine doesn't get disabled so the inhibitor isn't removed. It could also be that an inhibitor gets leaked, so when Caffeine is disabled to prepare for hibernate / shutdown there's still one left over.

Out of curiosity, if you can reproduce this reliably, could you try #334? It reworks how inhibitors are handled, so if that works it might be on our end.

[PhrozenByte]

When I triggered the bug before, sudo shutdown now gave me a complaint that a user session was inhibited, so this might be the case. If so, we'd need some kind of signal from the system that it wants to shutdown / hibernate manually, and then we'd drop the inhibitors.

systemctl poweroff / poweroff / shutdown now all work without a hitch. I guess that's expected though, because Caffeine's inhibitor only registers itself for sleep, not shutdown.

It could also be that GNOME started checking inhibitors before disabling extensions, meaning Caffeine doesn't get disabled so the inhibitor isn't removed. It could also be that an inhibitor gets leaked, so when Caffeine is disabled to prepare for hibernate / shutdown there's still one left over.

Is there a way to verify that? Like enabling a debug mode or something? Just let me know how I can help you to debug the issue.

Out of curiosity, if you can reproduce this reliably, could you try #334? It reworks how inhibitors are handled, so if that works it might be on our end.

I just tried with #334 and unfortunately the issue persists.

Off Topic: I had to check the loaded source code to verify that make install actually replaced the GNOME extension, because my extension manager doesn't give any indication about a extension's origin and it still shows Caffeine as version 55. I'd like to suggest injecting a version string with the commit hash in make build (could be a Makefile argument to overwrite it for stable releases).

[stuarthayhurst]

systemctl poweroff / poweroff / shutdown now all work without a hitch. I guess that's expected though, because Caffeine's inhibitor only registers itself for sleep, not shutdown.

Hm, I might have run into something else then

Is there a way to verify that? Like enabling a debug mode or something? Just let me know how I can help you to debug the issue.

I suppose you could put something like log("Caffeine shutting down") in disable() of extensions.js, and if it outputs "Caffeine shutting down" to journalctl -xf while attempting to manually hibernate then we might be leaking an inhibitor. I doubt that's the case since #334 didn't fix it, and also a manual hibernate should override anything we set.

I just tried with #334 and unfortunately the issue persists.

Oh well, thanks for checking. That PR completely changes how inhibitors are handled, so it's either an upstream issue or an issue with the inhibitor that we create, such as a bad flag or something like that.

Off Topic: I had to check the loaded source code to verify that make install actually replaced the GNOME extension, because my extension manager doesn't give any indication about a extension's origin and it still shows Caffeine as version 55. I'd like to suggest injecting a version string with the commit hash in make build (could be a Makefile argument to overwrite it for stable releases).

I'm not sure if the shell / extension tool would like that, but you're welcome to test if it breaks the update detection

[PhrozenByte]

I suppose you could put something like log("Caffeine shutting down") in disable() of extensions.js, and if it outputs "Caffeine shutting down" to journalctl -xf while attempting to manually hibernate then we might be leaking an inhibitor. I doubt that's the case since #334 didn't fix it, and also a manual hibernate should override anything we set.

I just added log("Caffeine shutting down"); right after disable(), but this log message doesn't even show up when manually disabling the extension 😕

It gets even weirder: If I change the version number in metadata.json, this change isn't reflected in gnome-extensions info [email protected], no matter whether I change it to a string (to include a commit hash) or another integer (like 56). However, gnome-extension install from make shows no error and exits with status 0. However, checking the extension's sources in the path reported by gnome-extension info indeed shows the updated extension's source code. What is going on? 😕

[stuarthayhurst]

Did you install it as a user? If you used root then it would install it for root instead. Also, did you log out and back in after making changes? Sometimes even that's not enough and I've had to reboot after making changes, but that's normally only if something had an error.