[Workaround] Entering hibernation on critically low battery level

svenper · 2016-08-23 15:16:49

I am trying to configure power management on my Lenovo ThinkPad E135. Currenly it seems to enter sleep on critical battery level, but I want it to hibernate instead. I know that hibernation is set up and working otherwise, by way of systemctl hibernate.

I do not want to use a desktop environment for this, unless someone can provide a compelling reason.

I tried the udev method, with no success.

I tried with TLP, but my hardware is not supported:

# tlp stat
. . .
+++ ThinkPad Extended Battery Functions
tp-smapi   = inactive (unsupported hardware)
tpacpi-bat = inactive (unsupported hardware)
. . .

I also looked on how to do it with acpid, but acpi_listen did not show any events for battery level change.

So it seems I'm SOL here, unless there's a workaround. I assume that somehing triggers the the computer to sleep on low battery, but I don't know what. If I find that out, would I be able to change it to hibernate instead? Is it maybe hard-coded in the kernel?

Last edited by svenper (2016-08-30 11:06:00)

Alad · 2016-08-23 15:44:36

Try the cron script below the udev rule

svenper · 2016-08-23 16:21:56

I can see why that would work, so I don't want to sound ungrateful (and I realize now that I asked for workarounds) but I really want to use a solution that goes by ACPI events. A cron job like that would run even at 100% battery, which isn't useful. I kind of want to do this the most precise way. How much battery impact would that cron job have? I'm guessing it's probably negligible?

Say the computer would be under very low load until the last 5%, and by a coincidence have the cron check, and then have the computer be under heavy drain. The battery could go all the way down to the system sleep trigger (at whatever percentage that is) without triggering hibernation, but me maybe thinking it hibernated and leaving it to die with unsaved work.

How would I go about figuring out what is currently causing the computer to sleep?

svenper · 2016-08-29 22:15:09

I removed tlp and powertop, then tried acpi_listen again. It still didn’t show anything on battery level change, but it did show a cryptic signal for something at around 5% battery:

battery PNP0C0A:00 00000080 00000001

Since there weren’t any other signals happening at the same time, I assumed this is the thing I’ve been looking for. If it didn’t appear before, I don’t know if it was because I only ran acpi_listen at higher battery levels, or because of interference from tlp or powertop (if that’s even possible?).

To make this signal trigger hibernation, I added this to the battery case of /etc/acpi/handler.sh:

# case "$1" in ...
    # button/power) ...
    battery)
        case "$2" in
            PNP0C0A:00)
                case "$3" in
                    00000080)
                        case "$4" in
                            00000001)
                                logger 'Critical battery level?'
                                /usr/bin/systemctl hibernate
                                ;;
                        esac
                        ;;
                esac
                ;;
        esac
        # case "$2" in ...
    # button/lid) ...
# esac ...

Edit: well, that’s irony for you: that same acpi event happened literally seconds after posting this, at 20% battery. The quest continues...

Last edited by svenper (2016-08-29 22:20:55)

Alad · 2016-08-29 22:41:40

How much battery impact would that cron job have? I'm guessing it's probably negligible?

Yes. You can see for yourself by checking powertop, or lacking that, top.

Regarding what causes your computer to sleep, that's hard to guess without further information. You can check if your firmware has particular functions for this, or if you have a particular process running with relevant functionality (e.g., upower).

As to the ACPI events, I have similar on my thinkpad; when the battery is below a certain percentage, the battery light goes orange and I get an ACPI event. If it drops even further, the light starts to blink and I get a second event. Of course, these same events stop occuring after ~10 suspend cycles.

If in your case the events happen in rapid succession, you could e.g. write a file to /var/run with a date stamp, and only hibernate if a certain time has passed. If for some reason the events also happen on AC, you can use /usr/lib/systemd/systemd-ac-power to check for that.

Last edited by Alad (2016-08-29 22:44:28)

svenper · 2016-08-29 23:37:13

The event seems to happen consistently on low battery, so for now I’ll just add a battery level check to the script. I’ll report back if something breaks.

CAPACITY=$(cat /sys/class/power_supply/BAT1/capacity)
STATUS=$(cat /sys/class/power_supply/BAT1/status)
if [ $CAPACITY -le 6 ] && [ $STATUS = Discharging ]
then
    echo $(date): $CAPACITY% >> /var/run/auto-hibernate.log
    /usr/bin/systemctl hibernate
fi

EDIT: after further testing, it seems to happen on plugging in the cable, at 80%, 20%, and 5% battery.

Last edited by svenper (2016-08-30 21:48:50)

Arch Linux

#1 2016-08-23 15:16:49

[Workaround] Entering hibernation on critically low battery level

#2 2016-08-23 15:44:36

Re: [Workaround] Entering hibernation on critically low battery level

#3 2016-08-23 16:21:56

Re: [Workaround] Entering hibernation on critically low battery level

#4 2016-08-29 22:15:09

Re: [Workaround] Entering hibernation on critically low battery level

#5 2016-08-29 22:41:40

Re: [Workaround] Entering hibernation on critically low battery level

#6 2016-08-29 23:37:13

Re: [Workaround] Entering hibernation on critically low battery level

Board footer