Plasma - hibernation on lid close

[glottophilos]

I am having an issue where Manjaro seems not to be respecting my Hibernation setting after this update. I set up a swap and everything a little while back as per the Arch forums, but since I updated, if I set to Hibernate on lid close, my laptop just cooks itself instead of actually hibernating. Sleep seems to work fine, other settings too, but hibernation is broken somehow.

[linux-aarhus]

@glottophilos

I am having an issue where Manjaro seems not to be respecting my Hibernation setting after this update. I set up a swap and everything a little while back as per the Arch forums, but since I updated, if I set to Hibernate on lid close, my laptop just cooks itself instead of actually hibernating. Sleep seems to work fine, other settings too, but hibernation is broken somehow.

Your local configuration does not change.

I cannot say if something has changed upstream - but this is something that rarely changes.

I am guessing - and the only thing I can think of is if you are using an encrypted system with an encrypted swap partition and therefore is using openswap hook.

Upstream has made some changes and the new default configuration will be created as /etc/openswap.conf.pacnew.

If you have merged the config without further examination you may have overwritten your working configuration with the default - non working - configuration.

[hasezoey]

What is your DE and what does the journal log say? If it is KDE, it may be related to the issue i had already posted in the previous update topic: [Stable Update] 2025-12-08 - 25.1 Anh-Linh Preview - #101 by hasezoey
Though i have not tried with that machine and this update again.

[glottophilos]

The DE I am using is KDE Plasma, it does look like it could be similar. It’s definitely the same at least insofar as it will hibernate properly with systemctl, but not via the lock screen or with lid close. My journalctl shows the following that I think might be useful:

systemd-hibernate.service: Main process exited, code=exited, status=1/FAILURE
systemd-hibernate.service: Failed with result ‘exit-code’
Failed to start System Hibernate.
Dependency failed for System Hibernation.
hibernate.target: Job hibernate.target/start failed with result ‘dependency’.

and a bit earlier in the logs (just a few lines) we have

Failed to put system to sleep. System resumed again: Device or resource busy.

Unfortunately the logs aren’t more specific so far on what the dependency failure is or whether that’s the limiting factor, systemctl status doesn’t show much different.

Edit: Also adding in the fact that these failure logs do not show up in systemctl status when I run systemctl hibernate, everything is totally clean.

[Aragorn]

@glottophilos

System resumed again: Device or resource busy.

It’s telling you, right there.

UNIX systems conduct a lot of work in the background — mostly when the system is otherwise idle, so as to not interfere with the user experience too much — because they were designed from the ground up as multitasking and multi-user operating systems on and for Real Computers™.

Hibernation and even CPU sleep are technologies developed specifically for consumerist appliances that originally did not run such powerful operating systems — i.e. Windows and (classic) macOS.

[glottophilos]

I mean I see that, yes, but that should stop, no? As I understood it, a hibernate command says “hey don’t keep doing things.” Plus as I noted, it is not working on lid close, but works just fine with systemctl directly, which says to me there is something wrong with the lid close behavior, not just that something indeterminate is happening in the background.

[Aragorn]

@glottophilos

I mean I see that, yes, but that should stop, no? As I understood it, a hibernate command says “hey don’t keep doing things.”

It depends on what those things are. They could be high-priority tasks — e.g. a filesystem sync, which is a kernel process.

@glottophilos

Plus as I noted, it is not working on lid close, but works just fine with systemctl directly, which says to me there is something wrong with the lid close behavior, not just that something indeterminate is happening in the background.

There have been some bug reports over at KDE with regard to laptop lid closing, and they were reportedly fixed, but I forgot in what version. Plasma is developing very rapidly, with new releases and bugfix releases coming out in rapid succession.

I can only recommend keeping an eye on the latest developments over at KDE, so as to stay informed.

[pwx]

--check-inhibitors=
When system shutdown or sleep state is requested, this option controls checking of inhibitor locks. It takes one of "auto", "yes", and "no". Defaults to "auto",
which means logind will perform the check and respect active inhibitor locks, but systemctl will only do a client-side check for interactive invocations (i.e.
from a TTY), so that a more friendly and informative error can be returned to users.  "no" disables the checks both in systemctl and systemd-logind(8).

Applications can establish inhibitor locks to prevent certain important operations (such as CD burning) from being interrupted by system shutdown or sleep. Any user may take these locks and privileged users may override these locks. If any locks are taken, shutdown and sleep state requests will normally fail (unless explicitly overridden with "no").

Option --force provides another way to override inhibitors.

Added in version 248.

-i
Shortcut for --check-inhibitors=no.

I always hibernate with the “-i” option because it is more important to me that hibernate works. However, I also make sure that no significant applications are running that might crash or generate errors after resuming.

[hasezoey]

Just as a update to my post in the last update, i re-tried hibernation via kscreenlocker with the laptop and it still happens; same error:
Freezing user space processes aborted after 0.000 seconds (54 tasks refusing to freeze, wq_busy=0): (for context also a later System resumed again: Device or resource busy, but no more information on what the issue is)
Though with a different warning (no more Inhibit unauthorized dbus message):
kwin_wayland[967]: Failed to delay sleep: The operation inhibition has been requested for is already running

I did some further research and found this related KDE issue, though there it mentions it for both sleep and hibernate and it is supposedly already fixed with plasma 6.5.3.
There someone suggested to try the kde start-menu hibernate option, which i found to also be working. Though i noticed that sometimes Hibernation (if successfully triggered) seemingly gets stuck after the journal message PM: hibernation: hibernation entry forever.

A workaround was to remove the executable bit from /usr/lib/kf6/kauth/wakeupsourcehelper and it seems to work for me.

To maybe help out the KDE team / kernel devs, please read this comment and reply with your hibernation device reason (in the thread there is already mmc0 and my case ADP1).

KDE About

Operating System: Manjaro Linux 
KDE Plasma Version: 6.5.4
KDE Frameworks Version: 6.20.0
Qt Version: 6.10.1
Kernel Version: 6.18.1-1-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 22 × Intel® Core™ Ultra 7 155H
Memory: 16 GiB of RAM (15,1 GiB usable)
Graphics Processor: Intel® Arc
Manufacturer: LG Electronics
Product Name: 17Z90SP-G.AA78G
System Version: 0.1

---

This might be worth splitting into its own discussion, though i dont know how to do that (and i couldnt find anything searching for that)

[linux-aarhus]

I have split the topic off to a separate thread.

Going over the comments related while

What we know so far:

• hibernation work as expected when invoked from the command line
• using a plasma setting (hibernate on lid) close does not
• log messages of various kind system inhibits hibernation

During my thought process I turned to Power management - ArchWiki

Power managers

Some desktop environments include power managers which inhibit (temporarily turn off) some or all of the systemd ACPI settings. If such a power manager is running, then the actions for ACPI events can be configured in the power manager alone. Changes to /etc/systemd/logind.conf or /etc/systemd/logind.conf.d/*.conf need be made only if you wish to configure behaviour for a particular event that is not inhibited by the power manager.

Note that if the power manager does not inhibit systemd for the appropriate events you can end up with a situation where systemd suspends your system and then when the system is woken up the other power manager suspends it again. The power managers of GNOME, MATE, Plasma and Xfce issue the necessary inhibited commands. If the inhibited commands are not being issued, such as when using acpid or others to handle ACPI events, set the Handle options to ignore. See also systemd-inhibit(1).

[hasezoey]

From what i could gather in the KDE Issue, this is a issue since about 6.5.0, because KDE introduced a inhibitor for some reason (likely what is mentioned in the quoted arch wiki), disabling that more-or-less completely fixes the issue.
Also note that for some reason that wakeup helper is only used for the lock-screen for some reason.

When disabling the wakeup helper (to get the same behavior as before plasma 6.5.0), there is no noticeable difference (ie no double suspend / hibernate as the wiki suggests)

Finally, if i understand the underlying issue correctly, this is a kernel bug that is triggered if you read /sys/power/wakeup_count and write-back the same count (which enables the feature), but later some subsystem actually does have a wakup event (that is not a interrupt?) the suspend / hibernate is aborted, even if that event is not necessary to be handled.

Kernel sysfs-power:

What: /sys/power/wakeup_count
Date: July 2010
Contact: Rafael J. Wysocki rafael@kernel.org
Description:
The /sys/power/wakeup_count file allows user space to put the
system into a sleep state while taking into account the
concurrent arrival of wakeup events. Reading from it returns
the current number of registered wakeup events and it blocks if
some wakeup events are being processed at the time the file is
read from. Writing to it will only succeed if the current
number of wakeup events is equal to the written value and, if
successful, will make the kernel abort a subsequent transition
to a sleep state if any wakeup events are reported after the
write has returned.

[linux-aarhus]

I beginning to see a vague picture of why hibernation is a non trivial task.

• Swap suspend — The Linux Kernel documentation

[glottophilos]

@hasezoey

From what i could gather in the KDE Issue, this is a issue since about 6.5.0, because KDE introduced a inhibitor for some reason (likely what is mentioned in the quoted arch wiki), disabling that more-or-less completely fixes the issue.

Just to double-check that I’m understanding properly, does it seem to you that disabling the helper is the solution? At least in the interim? Or is there still some larger solution we should be looking for from the KDE team?

[hasezoey]

@glottophilos

does it seem to you that disabling the helper is the solution? At least in the interim? Or is there still some larger solution we should be looking for from the KDE team?

It is a workaround, a temporary fix until a proper fix from KDE (or the kernel) is available.

---

I investigated a little more:
The fix they made for plasma 6.5.3 checks mem_sleep to be anything other than s2idle and does not write to wakeup_count.
The problem is that hibernation does not get listed in that file (mem_sleep) and that file is also not a indicator of what suspend mode is taking place, so hibernation takes the path to write to wakeup_count (which is our problem).

[glottophilos]

Got it! In that case, I’ll mark your post as the solution with the knowledge that it is essentially temporary, and we’ll keep an eye on that KDE bug report and see what happens from there. I did test and the workaround seems to do the trick for now on my machine as well.