Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.


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.

share|improve this question

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.

share|improve this answer
Hmm.. found an example at <…;. 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 2 '11 at 5: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 2 '11 at 5:17
Okay, maybe I just didn't read that article in enough detail.. I kind of skimmed it. – intuited Apr 2 '11 at 5: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 3 '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 3 '11 at 10:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.