Since upgrading from F41 to F42, I have noticed occasionally that I can’t suspend my computer. This was discussed in Poweroff/reboot doesn't work in GNOME, when an inhibitor is held, but that thread seems to get confused about what’s going on; and is focusing on the UI handling the situation.
In their problem, they see cinnamon blocking suspend, but in mine it’s gnome. I have to completly log out to clear that block.
Why is it blocking suspend?
This is really annoying because it doesn’t just block my attempts to suspend, it also blocks the timeout based suspend. So now my computer just sits all night without suspending. I can’t trust it anymore to turn off on it’s own. I have to turn it off myself.
$ systemctl suspend
Operation inhibited by "rolf" (PID 2727 "gnome-session-b", user rolf), reason is "user session inhibited".
Please retry operation after closing inhibitors and logging out other users.
'systemd-inhibit' can be used to list active inhibitors.
Alternatively, ignore inhibitors and users with 'systemctl suspend -i'.
Can you create a new user and see if it works? That’ll tell us if it’s a system issue or something related to the particular user.
If it works in a new user, we should then make sure all your extensions are disabled and then re-check. If it works then, we’ll re-enable the extensions one by one to see if it’s one of those and so on.
It’ll be good to look at the journal logs to see if there’s info there too:
I think I figured out what’s going on. I was running Emacs. As soon as I closed Emacs, “gnome-session-b” (which is actually gnome-session-binary) stopped blocking “sleep”.
I can’t reproduce this today. Whenever I start up Emacs (or any other editor), it only blocks “shutdown”, not “sleep”. But this happens to me every few days. I did catch this output during one of the times when it was blocking sleep.
rolf@endlisnis2024-11 ~/Pictures
$ systemd-inhibit
WHO UID USER PID COMM WHAT WHY MODE
ModemManager 0 root 1604 ModemManager sleep ModemManager needs to reset devices delay
NetworkManager 0 root 1657 NetworkManager sleep NetworkManager needs to turn off networks delay
UPower 0 root 1491 upowerd sleep Pause device polling delay
GNOME Shell 1000 rolf 2777 gnome-shell sleep GNOME needs to save screen time data delay
rolf 1000 rolf 2937 gsd-media-keys handle-power-key:handle-suspend-key:handle-hibernate-key GNOME handling keypresses block
rolf 1000 rolf 2727 gnome-session-b shutdown:sleep user session inhibited block
rolf 1000 rolf 2937 gsd-media-keys sleep GNOME handling keypresses delay
rolf 1000 rolf 2939 gsd-power sleep GNOME needs to lock the screen delay
I can understand why it would block shutdown if you have open (unsaved) files, but I don’t see why it would block sleep.
Hrm, yeh, that’s tricky to debug. Perhaps it depends on what emacs is doing? I didn’t know editors blocked anything tbh—I thought it’d shut down without worrying about that.
Well, the bug here is that it does not say that “Emacs” is doing anything, it says that “gnome-session-binary” is blocking suspend.
Many editors will block shutdown if they have unsaved changes, but they do that with an interactive prompt. Not by just blindly blocking the shutdown action.
I caon confirm this behavior as well, it might be a bug in Nautilus perhaps? I moved files (from a local disk to an SMB share, should that matter), and even hours after this was completed, the system still didn’t let me hibernate.
Hadn’t I found this thread, I would simply have restarted the computer instead of looking for the root cause and disregarded it as another hibernation hiccup.
Linux copies files in the background, so it will tell you the copy is complete way before it’s actually done copying all the files. I’m wondering if the files were still copying in the background, in which case the inhibit makes sense. I don’t know how to check that, but maybe someone else can provide a way to check if the file copy is still in progress.
I can’t imagine that copying these files would have taken so long. However, should it really be the case that Nautilus reports success (i.e. shows 100% progress) before the file is actually, truly finished copying, that would be an even bigger issue in the program, imho. I’m relying on this information to decide on whether I can work with the copy, disconnect removable media, etc.
This just had this happen again today. I completed downloading a file in Chrome. I ran sync. I waited literally over an hour after it said it was finished.
$ gnome-session-inhibit --list
/usr/bin/google-chrome-stable: Download in progress (suspend)
I don’t think that Emacs, Nautilus, and Chrome suddenly have the same bug. Gnome is missing or losing notifications about the end of that suspend restrictions.
Is there a place to report this bug? I looked at Making sure you're not a bot!, but I don’t know what project to report it to. I read the long list of projects, but none of them seem a good fit.
In that case sync wouldn’t help since it only handles FS syncing… the best explaination I can come up with is that the apps in question have some method to prevent suspension (which makes sense), but either the apps or gnome don’t clean this up when finished.
I think, the official place to file a bug is still Fedora’s Bugzilla: How to file a bug :: Fedora Docs
Since the package isn’t directly published by GNOME, it could theoretically be possible that this is a Fedora-specific bug, which the package maintainer should be able to find out.
