Always hibernate before power runs out

Framework Laptop 13 Linux
1

I’m running Manjaro + KDE and in the KDE settings I have it configured so that when it is on low power (<= 20%), it will sleep after 5 minutes of inactivity and hybernate “after a period of inactivity”. I’ve also configured in the advanced power settings to hybernate at a critical level which I’ve configured to 5%.

Last night I was using the laptop, I’m not sure what level it was on when I closed the lid except that it was on low power. When I picked it up this morning it had drained completely. I’ve definitely had it hybernate several times, including at the critical level while I was using it but apparently it’s not entirely reliable. Is there anything I can do to help increase the reliability of these low power features?

1 Like
2

Sorry to hear about that. Suspend (unless it’s configured for deep sleep) will still drain over night, just at a slower rate.

Regarding hibernation, did you manually configure it?

1 Like
3

I’m using the hibernation support that Manjaro autoconfigured in the installer.

I’m very familiar with Linux in general, I’ve been using it for years on my desktop but this is my first linux laptop ever, so I’m not too familiar with the power features yet.

Other than the changes I’ve made in the KDE settings panels I haven’t configured anything to do with power levels yet. For the sake of completeness, here’s my current settings:

image
image1177×1132 152 KB

image
image1173×1121 151 KB

I’m 95% sure I’ve had it go from sleep mode to full hibernation in at least some circumstances, but I could be wrong there.

4

And just to be clear on my expectations, I understand that unless it goes into hibernation mode it will drain battery, I just want to be sure that it always makes it to hibernation mode if it’s running low on battery rather than draining completely and potentially losing what I was working on.

5

My guess is that you should set the system to hibernate after a period of inactivity both for battery and for low battery. You may be hitting sleep when the battery level is not considered low, but then draining the remaining amount while in sleep mode. I may be wrong, but I would be surprised if the system is able to detect that it has gone from battery to low battery while asleep.

6

After brushing up on the Arch wiki on suspend and hibernate, I think what I’m actually looking for is the “hybrid sleep” option when closing the laptop lid. What that seems to be is a combination of saving RAM to swap as per full hibernation, but then drop into S3 sleep instead of S4 for a faster resume if possible. That way, if it does accidentally fully drain, I can plug it back in and resume as if it had hibernated instead. I’m not quite sure why this isn’t the default in favour of regular sleep mode if hibernation is supported, but oh well. It seems like the best of all possible worlds - quick resume if the battery doesn’t drain, safety with a longer resume in case it does.

1 Like
7

Systemd supports four power-saving modes: suspend, hibernate, hybrid-sleep and suspend-then-hibernate. Very briefly each one behaves as follows:

  • suspend: Save state to RAM, battery still drains at a slow rate, when drained completely you lose your data, fast sleep, fast resume
  • hibernate: Save state to disk, battery does not drain (powered off), slow sleep, slow resume
  • hybrid-sleep: Save state to RAM and disk, battery still drains at a slow rate, your data is safe if drained completely, slow sleep, fast resume (unless fully drained)
  • suspend-then-hibernate: Save state to RAM, battery still drains at a slow rate. When the battery is low, it sends a signal that wakes the computer. Then it saves its state to disk and shuts off (hibernates). In this mode, sleep is fast and resume is fast unless the battery drains (slow resume). No data loss.

The above behavior applies to systemd 252, which was released 20 days ago. Manjaro still runs systemd 251, that behaves differently for the suspend-then-hibernate case:

 suspend-then-hibernate
       A low power state where the system is initially suspended (the state is stored in RAM).
       If not interrupted within the delay specified by HibernateDelaySec=, the system will be
       woken using an RTC alarm and hibernated (the state is then stored on disk).

In fact, this recent thread from the framework community warns of the change.

I do not use KDE so I cannot say what is happening in your system, but I assume checking the “While asleep, hibernate after a period of inactivity” box enables suspend-then-hibernate.

Since you are still running the old systemd, this explains why after you went into suspend-then-hibernate mode while your battery was low it drained completely: the expected behavior is to wake up after a certain time and then hibernate, but if the battery drains out before this can happen, then you lose your data.

This is actually the reason why the changes in systemd v252 were introduced (see the GitHub issue), to guarantee that the system goes into hibernation if the battery drains below a certain threshold in order to avoid data loss.

However, I believe this solution is still not ideal for framework laptop users, because of the still relatively high battery drain during suspend. With the old behavior, as long as you had sufficient power when closing the lid, you could open your laptop one week later and resume your work where you left it. With the new behavior, after a week you power on your laptop and then need to look for your charger in a rush because it is nearly drained.

The best solution in my opinion is a combination of both: after you close the lid, the computer can go into hibernation for two reasons; either sufficient time has passed, or battery is almost drained. This behavior avoids data loss while enabling both fast sleep, fast resume (at least for this “sufficient time”, after which resume is slow) and prevents excessive battery drain, so I think it is the best.

Fortunately, somebody already complained about the new behavior on the GitHub issue, and it seems systemd developers will change the behavior again to this last one I described for the next major release.

For the framework team: I believe it makes sense to make sure that the person you hired for Linux support has taken a look at the GitHub issue and even participates in the discussion/development if needed, since this is an important ux issue.

7 Likes
8

Thanks for the rundown. The 252 update sounds like an improvement, but I think you’re right that ultimately a combination of both is probably best in the long term. I’ll keep an eye out for that update, it looks like it’s on the unstable branch already, but in the meantime I guess the best option is still hybrid sleep for now.

9

Appreciate the heads up to this and I will definitely begin to tackle this. Now that I have a clearer picture as to the op’s desired behavior, I can set aside a laptop for some further testing and so forth.

At the moment, we’re deeply working strictly with suspend behaviors (on Ubuntu, Fedora, etc) and this will be a part of that process going forward.

3 Likes