Desktop stops suspending after some time due to gsd-power handle-lid-s

seventeen · 2026-05-13 14:56:45

Hi everyone,

I'm encountering an issue on my Arch Linux desktop where the system stops automatically suspending after running for some time. This has happened on both GNOME 49 and GNOME 50.

When the system refuses to suspend, I checked systemd-inhibit --list and found the following entry blocking the suspend:

username     1000 username 3160 gsd-power      handle-lid-switch      External monitor attached or configuration changed recently block

The system is a standard desktop PC, so it does not have a lid. I initially suspected a system update was causing this, but the issue appears randomly even without any updates.

Looking at journalctl logs for systemd-logind, the system suspends properly earlier in the day but eventually stops attempting to suspend entirely. There are no errors displayed, just an absence of suspend events:

May 11 00:51:34 my-arch-desktop systemd-logind[849]: The system will suspend now!
May 11 08:54:38 my-arch-desktop systemd-logind[849]: Operation 'suspend' finished.
May 11 09:09:38 my-arch-desktop systemd-logind[849]: The system will suspend now!
... [suspends normally a few more times] ...
May 11 22:29:05 my-arch-desktop systemd-logind[849]: The system will suspend now!
May 11 22:33:33 my-arch-desktop systemd-logind[849]: Operation 'suspend' finished.
May 13 22:32:07 my-arch-desktop systemd-logind[849]: Watching system buttons on /dev/input/event16 (Logitech USB Receiver Consumer Control)
May 13 22:32:07 my-arch-desktop systemd-logind[849]: Watching system buttons on /dev/input/event14 (Logitech USB Receiver)
May 13 22:32:07 my-arch-desktop systemd-logind[849]: Watching system buttons on /dev/input/event17 (Logitech USB Receiver System Control)

(Notice that there were no suspends triggered on May 12th, despite the machine being used).

System Information:

OS: Arch Linux (Kernel 7.0.5-zen1-1-zen)
DE: GNOME Shell 50.1 (Also occurred on GNOME 49)
GPU: NVIDIA GeForce RTX 4070 Ti (Proprietary nvidia driver)
Logind configuration: /etc/systemd/logind.conf is completely default (all lines commented out).

Has anyone else encountered this stuck gsd-power inhibitor on a desktop machine without a lid? Are there any known workarounds specifically for GNOME to ignore lid-switch events on a desktop to prevent this block?

Any help or pointers on debugging gsd-power would be greatly appreciated!

seth · 2026-05-13 21:20:27

https://gitlab.gnome.org/GNOME/gnome-se … _items/111 (brace yourself and remember to breath into a paper bag if you feel you start to hyperventilate…)

seventeen · 2026-05-14 06:13:50

seth wrote:

https://gitlab.gnome.org/GNOME/gnome-se … _items/111 (brace yourself and remember to breath into a paper bag if you feel you start to hyperventilate…)

Hi seth,

Thanks for the reply. I have checked this issue before but i don't think it applies to my case.

I am on a desktop PC instead of a laptop. So there's no "external monitor", but only one primary monitor being attached.

seth · 2026-05-14 08:14:55

I am on a desktop PC instead of a laptop.

Why do you think gnome would care about such corner cases…
There's an external output so we need to deactivate the lid switch which implicitly somehow disables the autosuspend because when there's an external monitor you're running on a dock and then don't want to have the system autosuspend.
Hardcoding personal preferences about a local system as universal defaults is kinda gnomes MO and the entire inhibition thing is a broken mess since a decade now

My best guess would be to snoop around in the gnome power settings and see whether you can do anything about the lid switch behavior at all.
Wrt "after some time", I assume the inhibitor doesn't exist before that?
The trigger might be a reconnection of the output (what can technically happen during DPMS or maybe powering off the monitor w/o physical reconnections)

Luckily there seems to be absolutely no reasonable way to remove inhibitors (but for killing the inhibiting process) so you'd have to re-login to clear the stage.
Can you re-establish it by reconnecting or powercycling the monitor?

The brute-force "solution" might be to disable "InhibitorsMax=0" in logind.conf

seventeen · 2026-05-15 13:57:42

My best guess would be to snoop around in the gnome power settings and see whether you can do anything about the lid switch behavior at all.

There is no settings related to lid in the gnome power settings, and it makes sense since I'm on desktop instead of laptops.

Wrt "after some time", I assume the inhibitor doesn't exist before that?
The trigger might be a reconnection of the output (what can technically happen during DPMS or maybe powering off the monitor w/o physical reconnections)

Yes. After reboot there is no

handle-lid-switch

It just appears after sometime.

seth · 2026-05-15 15:43:52

Can you cause it by reconnecting or power cycling the monitor?

Arch Linux

#1 2026-05-13 14:56:45

Desktop stops suspending after some time due to gsd-power handle-lid-s

#2 2026-05-13 21:20:27

Re: Desktop stops suspending after some time due to gsd-power handle-lid-s

#3 2026-05-14 06:13:50

Re: Desktop stops suspending after some time due to gsd-power handle-lid-s

#4 2026-05-14 08:14:55

Re: Desktop stops suspending after some time due to gsd-power handle-lid-s

#5 2026-05-15 13:57:42

Re: Desktop stops suspending after some time due to gsd-power handle-lid-s

#6 2026-05-15 15:43:52

Re: Desktop stops suspending after some time due to gsd-power handle-lid-s

Board footer