KDE PowerDevil Systemd Inhibit

rrs@researchut.com (Ritesh Raj Sarraf) — Tue, 28 Oct 2025 00:00:00 +0000

With KDE 6.5.0, PowerDevil has ~~broken~~ forced its own set of suspend/hibernate inhibitors onto logind. And to my knowledge, there’s no way to disable them.

As a user, I’d prefer to set lid action as Do nothing and really expect KDE/PowerDevil to do nothing in that regard. But with KDE 6.5.0 PowerDevil forces those inhibitors whatsoever.

❯ systemd-inhibit --list
WHO UID USER PID COMM WHAT WHY >
ModemManager 0 root 3541 ModemManager sleep ModemManager needs to reset devices >
NetworkManager 0 root 3453 NetworkManager sleep NetworkManager needs to turn off networks >
UPower 0 root 4342 upowerd sleep Pause device polling >
PowerDevil 1000 rrs 82735 org_kde_powerde handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch KDE handles power events >
Screen Locker 1000 rrs 4844 kwin_wayland sleep Ensuring that the screen gets locked before going to sleep >

5 inhibitors listed.

This essentially prohibits logind to act on the lid actions. And instead forces the user to depend on nothing else and other than PowerDevil. This assumes the wishful thought that PowerDevil is Solid.

I’d love to continue using my suspend workflow via systemd’s suspend-then-hibernate target as it has been working reliably for years. And it also allows me to customize the behavior as I see fit.

Of course, I do have the option to trigger systemd suspend-then-hibernate manually, every time, before closing the lid. But computers and automation has spoilt things.

The quick workaround/fix is to delegate it to ACPI, on platforms that support it. Thankfully all of x86 to my knowledge.

So, in ACPI actions I’ve a new config set to:

❯ cat /etc/acpi/actions/lm_lid.sh
#! /bin/sh

grep close /proc/acpi/button/lid/LID/state && systemctl suspend-then-hibernate

And with that I can be back to reliably (and carelessly) suspend-then-hibernate my laptop.

PowerDevil on RESEARCHUT

KDE PowerDevil Systemd Inhibit