(In reply to comment #0)
> I don't understand why 'Suspend' wouldn't be allowed in the values for the
> PercentageAction and TimeAction.
> 
> My use case is: I'm using my laptop, and run out of battery (I forgot to
> plug the charger, in most cases, or I thought it was plugged and it isn't).
> It's nice if I can configure it to suspend, so I see the screen turn black,
> and I have time to find and plug the charger.
> 
> A quick web search reveals that many people are in my case.
> 
> I think it wouldn't hurt to allow users to configure the option "suspend to
> RAM" when the battery runs out.

If you suspend to RAM when the battery runs out, it will promptly die as if you didn't do anything. Suspending to RAM requires battery. If there's no battery, then you can't suspend to RAM...

I fail to see how this is a good idea.

Say I forget to plug my charger, then my battery reaches 5%, which means the laptop can run something like 10 minutes on battery before dying abruptly, losing my work.
At that moment, my laptop suspends, I notice it, and have several hours to find my charger and plug it before it completely runs out of battery.

If it hadn't suspended, it would halt abruptly when reaching 0% without me noticing.


Actually, I already have a script that does this by polling, and was hoping it could be integrated in upower to avoid the overhead.
I have distributed that script when asked, and it is very widely used, and considered a life-saver.

Without this function, people reach 0% and their laptop abruptly halts, without them having a few minutes to plug their charger.
It's not necessary to suspend to disk just for that.

(In reply to comment #2)
> Say I forget to plug my charger, then my battery reaches 5%,

It's 2 percent by default but we actually prefer to use time-based policies, so it would be 2 minutes of battery left.

> Without this function, people reach 0% and their laptop abruptly halts,
> without them having a few minutes to plug their charger.
> It's not necessary to suspend to disk just for that.

Their laptop will abruptly halt if there's no desktop environment running that checks on the warning level for that battery. There's also no need to poll, we send out D-Bus signals when the warning level changes.

Allowing suspend in there seems like a great way for users to shoot themselves in the foot by losing their work without a proper shutdown. On systems where hibernation is possible, or hybridsleep is possible, that will actually be preferred.

So I really don't see a good reason to add a Suspend option, and for your use case, it can be implemented in a small script without interfering desktop environments or UPower.

I'll leave this opened for Richard to look at, if he thinks it's a good idea. I don't.

Note that just _allowing_ this value doesn't break anything, doesn't force anything on anybody: it just allows more.
And incidentally saves the hassle to listen to events with a separate script. :)

> Note that just _allowing_ this value doesn't break anything, doesn't force 
> anything on anybody: it just allows more.
+1

Some users *want* to shoot into it's own foot.
I'm loosing my work because it's powering off instead of going into suspend. I agree, this shouldn't the default, but works for me.
My laptop can survive at least 30min - 1h in suspend when reaching critical level.

I also see no good reason not to allow suspend as a action. Sure, list caveats in the documentation if you must, but I am also a user who has unnecessarily lost work on several occasions due to unexpected power-off. My laptop easily lasts at hour if I suspend at 5% charge state. This is often more than enough time to find power.

See also: https://bugs.freedesktop.org/show_bug.cgi?id=99658 Allow "ignore" action on critical battery level

Created attachment 134166 [details] [review]
allow Suspend as CriticalPowerAction

Suspending uses power. I don't possibly know how this would be a good idea.

Hi Richard,

I don't want to set this as default. But for rare cases (like me and others) this is useful.

My setup doesn't support hibernate. When it comes to the critical event, the system shut's down. So I'll loose all my state. But when it go into suspend, I've a lot of time (usually between 30 minutes and 2h) to find the power supply.

This patch doesn't touch the default behaviour, only for users who set this explicit in the configuration file.

+1 to "comment 10", I'm in exactly the same situation.
Suspend used to be available as critical action a few years ago and worked perfectly for me. It's not available these days and I lost work twice because of this. I consider this a regression from the old days.

Suspending gives the user a notification of the low battery situation that's impossible to miss (the screen goes black) and time to plug in the power supply.

And I don't possibly know how it could be justified to disallow users from setting the value they'd like on a parameter.
This is simply autocratic.

Again, nobody wants this to be the default.

I would also very much appreciate being able to set this value on systems which do not have access to writable storage, or writable storage so slow that the computer would run out of battery only trying to write the RAM contents to it!

(In reply to Richard Hughes from comment #9)
> Suspending uses power. I don't possibly know how this would be a good idea.

As well as I know the hibernation in linux is currently not mature enough for everyday use. There has been a reason disabling it by default! Desktop is very slow after resume in many cases(e.g. when ram in use is more than half the total ram on hibernation point. Take a look at TuxOnIce project).

Hibernate not being enabled by default, the default behavior on battery low is power off. Suspend, for obvious reasons, is not the ideal option in a "low battery situation" but considering the hibernate status it's the best we have(better than a power off!). BTW, as well as I remember it was the default action pre-upower days(correct me if I'm wrong)

A Sh: your remark is both correct *and* besides the point.

You're answering as if this RFE was asking to change the default value, which it isn't.

While the current *defaults* are perfectly fine as you mentioned, the topic at hand here is to *allow* another value to be manually set by users who wish to use it.

Again: this is not about changing anything. It is about *not forbidding* custom configuration for people whose setup and use case makes it the best for them, as explained at length already.

Please take due note that *allowing* a value to be set for a given option cannot possibly affect anybody using the software.
Unless you are offended at the idea that people could see that it is indeed possible to set this value if they want to. But such thought police would be scary.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/upower/upower/issues/59.