3

I'm running the openbox WM and would like to avoid loading the gnome stack. One of the lingering issues I have to resolve is avoiding abrupt system crashes due to depleted battery power.

Is there a low-profile, low-dependency daemon that will handle this situation? I'd like to be able to configure it to, for example, drop the system down into hibernation at 4% battery life if the AC is not connected.

I suppose I could just write a little cron job to poll /sys/.../batt*/.. and /sys/.../ac*/... every 10 minutes or so, but it seems like there might be some edge cases that need tending.

update

laptop-mode-tools sounds promising:

It ... supports various ... power management features, such as ... automatically hibernating if battery levels are too low...

However, it doesn't seem to be possible to install it in Maverick without relatively dire consequences.

On my system, its installation also requires the removal of the acpi-support package, which sounds sort of ominous.

intuited
  • 7,385

1 Answers1

1

You are very probably already running it: acpid. If the GNOME or KDE stuff is already installed then you'll find a bunch of ACPI event handlers already in /etc/acpi/events and scripts run in response to those events in /etc/acpi itself; you can modify or replace those scripts with your own handlers.

Unfortunately, there doesn't appear to be a lot of documentation included with Ubuntu about what events are available, and the handlers I see provided with acpid and acpi-support don't appear to include anything that tracks the battery level. Since ACPI should be providing events for that, you may have to experiment with /usr/share/doc/acpid/examples/default* to see what events are actually delivered so you can write handlers for them.

geekosaur
  • 11,787
  • Hmm.. found an example at http://mindspill.net/computing/linux-notes/acpi/acpi-low-battery-warning.html#acpi_event. Though I'm not sure I understand when the event(s) battery.* get triggered. Also I was hoping for something that would abstract away all the gritty polling and /proc/**/* bits. – intuited Apr 02 '11 at 05:11
  • Hm, acpid should be doing that for you; the ACPI BIOS sends the battery.* events, and you would have an /etc/acpi/events/battery which selects for battery.* events and runs a script to act on them. The script examines the name of the event to see what triggered it, and if it's a "battery low" event should do a shutdown or suspend. – geekosaur Apr 02 '11 at 05:17
  • Okay, maybe I just didn't read that article in enough detail.. I kind of skimmed it. – intuited Apr 02 '11 at 05:23
  • Hmm.. what I mean is that there is not actually a "battery low" event, you have to poll some system-dependent resource in /proc or /sys to find out why a battery event was generated. At least it looks that way:::::: I just dropped down to 0% battery capacity (according to wmbattery). I've set up an event handler /etc/acpi/events/log-all-events that responds to event=.* with a call to /usr/bin/logger '%e'. The only event that was registered when I hit 0% capacity was battery BAT0 00000080 00000001. The exact same message is generated when I connect or disconnect the AC. – intuited Apr 03 '11 at 10:15
  • I use the term "poll" loosely there, since it's not actually going to be checking every minute or whatever. But it will be required to check every time the AC connection status changes.. and more to the point, it will be required to check, period, when I was hoping it would just get the message from ACPI that the battery was low. – intuited Apr 03 '11 at 10:16
  • More detail: the only messages that have been logged during the 12 hours or so that I've had that event handler active, with the exception of the above-mentioned low-battery-power message, have been in response to AC connection and disconnection. – intuited Apr 03 '11 at 10:20