Action on critical battery isn't triggered

Toshiba A100-062, one battery, one frustrated user :|

Same here. It also worked fine for me in Feisty. In Gutsy this actually caused me to lose data.

It seems to work if you disable using the time for actions (somewhere in gconf). I do not see why, however, since the estimated time remaining seems quite correct.

However when it reaches ~5 minutes (also the threshold for critical battery) the time remaining is *no longer shown* in the tooltip over the red battery icon. I only see the percentage. As far as I know I am receiving no low battery warnings either (other than the tray icon changing).

This bug should be increased in priority/severity, especially since the workaround can only be accessed through gconf, and not through the UI.

If there is any data I can provide, please let me know.

(Could be seen as related to Bug #64751 / Bug #61201 )

(Might also be related to Bug #113244 )

can you check if thats still the case with the most recent version of gnome-power-manager ?

Same with the last version, see the Bug #136777

It as been nominated for gutsy, but it as been marked as duplicate of this ... -> please nominate it for gutsy !

This bug is critical and confirmed, not incomplete ...

Yes, same issue with the latest version.

I think I can maybe offer some explanation for (at least my) part of the problem.

The critical_action in gconf is set to 120 seconds of time remaining. As I wrote previously the lowest my remaining time indicator in the g-p-a tooltip never goes below 5 minutes... it disappears after that (it also seems to go in 5-minute steps, ie. 10min, 5min, disappeared). So I am guessing it never internally reaches 120 seconds.

I changed the critical action to 300 seconds (5 minutes), no luck. However when I set it to 360, it now works as it should, hibernating when there are 6 minutes remaining. Switching to percentage-based thresholds is also a workaround for the problem.

This bug is critical as Fabien said, simply because it exists in the default setup and has a very high risk of data loss for unsuspecting users.

Hurry up !!!!

You can't forget this critical bug !!

I can confirm this happens on a Thinkpad R50p. Laptop will suspend and hibernate manually, and suspend on lid close (my setting) so power management seems to work. However, saw this problem in the RC and earlier series and wanted to check if it was fixed in the final. In a test run on my system, GPM reported that the battery was critical and it would hibernate in a few minutes (this with under 5 minutes of power left). I was expecting it to do so but instead it simply allowed the entire system to crash. The BIOS power alarm came on as well but GPM didn't do anything other than warn it was going to hibernate, then failed to do so.

So that's any easy fix. Just switch it to default to percentages rather than percent. Is there something wrong with that? IT's probably easier than fixing the time reported issue. mine is now set to be critical at 3 and hibernate at 2%, the default percentages. Seeing how i get somewhere between 2-3 minutes per percent when using my big battery, and light load as typical, and I don't use the small one often, this seems very reasonable.

I can't believe one check box fixes this problem, yet no fix has been released. Now i have to fix my bad attempt at fixing this problem. My computer has been hibernating itself very often, haha.

Asus Z99H
suspend_to_ram works but suspend_to_disk didn't work on edgy and feysty either (gutsy also :( )
I can see, that battery level is critical, in power-management applet on panel

Where (in what exactly files should I change the settings?)

I found /etc/laptop-mode/laptop-mode.conf

# Should laptop mode tools perform auto-hibernation?
ENABLE_AUTO_HIBERNATION=0
AUTO_HIBERNATION_BATTERY_CHARGE_PERCENT=2
AUTO_HIBERNATION_ON_CRITICAL_BATTERY_LEVEL=1

I tried to set
ENABLE_AUTO_HIBERNATION=1
AUTO_HIBERNATION_BATTERY_CHARGE_PERCENT=4
AUTO_HIBERNATION_ON_CRITICAL_BATTERY_LEVEL=1

but no luck :\

still I found sth about hibernate /etc/default/acpi-support
# Set the following to "platform" if you want to use ACPI to shut down
# your machine on hibernation
HIBERNATE_MODE=shutdown

Same problem in nx7300 HP laptop (1,8 Mhz, 1GB Ram, 1GB Swap, 80 GB HD) :(
I can hibernate in System / Quit.
But It doesn't hibernate when the battery is critical.
I change the Configuration Editor changed time for policy, and the percentages. Not works :(
Version: Ubuntu 7.10 Final.

I can confirm this bug is critical.

Note that the laptop-mode.conf settings won't help. Ubuntu has taken the laptop-mode-tools package from Debian, ripped its guts out (the part that listens on ACPI events) and failed to mention this anywhere in the config files. By default, the whole thing is even disabled. Again, no mention in the laptop-mode.conf config file. You have to go into /etc/default/acpi-support to even enable the default functionality, with no mention of this in laptop-mode.conf. In the mean time, most of the *other* functionality is still broken. Especially this bit, since it depends on the laptop-mode-tools ACPI events. I might be accused of various things for suggesting this (and people will probably be right), but one could try installing the Debian version , set HIBERNATE_COMMAND=/etc/acpi/hibernate.sh and it'll probably work. The Debian package is in fact fully compatible with Ubuntu, except that it doesn't listen to what acpi-support says -- a good thing IMO.

http://samwel.tk/laptop_mode/packages/debian

to Bart Samwel :

Does Ubuntu's default laptop-mode set commit intervals and such things back to the default to prevent losing 10 minutes of data when battery is critical ? If not we should definitely file a bug for that.

Same on IBM Thinkpad R60 and R60e - when battery is low, nothing happens except the textual notice from power manager. The PC does not shutdown and runs until the battery is absolutely empty.

The same here, my laptop doesn't shutdown when the battery is critical. I have tried to search for those gconf keys that you mention here and in my system they don't exist, at least battery_critical_*.

Anyone can help us?

Hi

I have been checking again all the gconf keys and now it's working. The problem is that the keys are different named, so I couldn't find them. The solution has been to unchecked the use_time_policy. I don't know why is not working with the time policy, but now everything is running.

The thresholds are in a sub folder and there you can change them as you want (time policy and percentage policy thresholds).

Daniel

Hi,

i recently unchecked the gconf key
gnome-power-manager -> general -> use_time_for_policy
on my Thinkpad R60 and R60e; now it seems to work again.

I did this utilizing the application gconf-editor (for those who want to change this value, too).

Andreas

I own a Lenovo 3000V100 which I have now upgraded to Gutsy and faced the same problem (while this was not a problem in the prev version).

I read your comments and noticed that in the file /etc/laptop-mode/laptop-mode.conf the hibernate script path is /usr/sbin/hibernate which doesnot exist in my installation.

I changed this as below and I am now waiting for my battery to drain to see if it works:

# HIBERNATE_COMMAND=/usr/sbin/hibernate
HIBERNATE_COMMAND=/etc/acpi/hibernate.sh

FYI the /etc/acpi/hibernate.sh works perfectly if you run it manually.

I will let u know of the outcome however you can try it yourselves as well.

Nicolas

Unfortunately no luck on the above; the laptop went dead as usual... :(

Could you please try to see if the gnome-power-manager commands working for you on your laptop? Specifically:

gnome-power-cmd.sh suspend

That sends the DBUS message to the GNOME Power Manager and uses it's suspend routine.

I have tried it and it's working, but I'm using s2disk instead of linux
kernel suspend commands because they don't work on my laptop.

Daniel

On Dec 20, 2007 12:54 AM, Ted Gould <email address hidden> wrote:

> Could you please try to see if the gnome-power-manager commands working
> for you on your laptop? Specifically:
>
> gnome-power-cmd.sh suspend
>
> That sends the DBUS message to the GNOME Power Manager and uses it's
> suspend routine.
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https://bugs.launchpad.net/bugs/135548
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
··························································································································································
PhD Candidate
Cátedra Ceta-Ciemat de la Universidad de Extremadura
Universidad de Extremadura
··························································································································································
Por favor, NO utilice formatos de archivo propietarios para el
intercambio de documentos, como DOC y XLS, sino HTML, RTF, TXT, CSV
o cualquier otro que no obligue a utilizar un programa de un
fabricante concreto para tratar la información contenida en él.
··························································································································································

same bug on dell xps m1330 with gutsy updated daily.

Mine also works with either suspend or hibernate; it also works with the
laptop lid closed (goes to sleep mode).

The problem is with sleep when on battery or hibernate when on critical
battery.

On 20/12/2007, Ted Gould <email address hidden> wrote:
>
> Could you please try to see if the gnome-power-manager commands working
> for you on your laptop? Specifically:
>
> gnome-power-cmd.sh suspend
>
> That sends the DBUS message to the GNOME Power Manager and uses it's
> suspend routine.
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https://bugs.launchpad.net/bugs/135548
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Nicos Christodoulou
SciCane Ltd.

1A Technis Str.
CY-3055 Limassol

Tel. (+357)70006670
Fax (+357)25821239

<email address hidden>
<email address hidden>

This email and its attachments may be confidential and are intended solely
for the use of the individual to whom it is addressed. Any views or opinions
expressed are solely those of the author and do not necessarily represent
those of Scicane Ltd.
If you are not the intended recipient of this email and its attachments, you
must take no action based upon them, nor must you copy or show them to
anyone.
Please contact the sender if you believe you have received this email in
error.

Same problem here with Gutsy on a Quanta mw1.
Doing:
killall -9 gnome-power-manager;gnome-power-manager --no-daemon --verbose > ~/gpm.log 2>&1
when battery has 11% of power.
as seen in:
http://en.opensuse.org/Bugs:GNOME
http://bugzilla.gnome.org/show_bug.cgi?id=506305
got me the file attached.

Should get low power notification at 10%, critical at 3% and action (shutdown) at 2%, but no notification with anyone and no action too.
But executing "gnome-power-cmd.sh shutdown" in a terminal works perfect.

Hope this could help.

I messed with /etc/laptop-mode/laptop-mode.conf and now I don't suffer from the bug. Basicly I did quite the same stuff as jurgis.pralgauskis (few posts above)

My config:

#
# Should laptop mode tools perform auto-hibernation?
#
ENABLE_AUTO_HIBERNATION=1

#
# The hibernation command that is to be executed when auto-hibernation
# is triggered.
#
HIBERNATE_COMMAND=/usr/sbin/hibernate

#
# Auto-hibernation battery level threshold, in percentage of the battery's
# total capacity.
#
AUTO_HIBERNATION_BATTERY_CHARGE_PERCENT=2

#
# Enable this to auto-hibernate if the battery reports that its level is
# "critical".
#
AUTO_HIBERNATION_ON_CRITICAL_BATTERY_LEVEL=1

Gnome-power manager notifies me about the low power and critical status of the battery so maybe it (and not laptop mode) starts the hibernation. In that case the bug has probably been fixed...

I have the same problem.
Notebook: Asus Z92J (kinda AJ6 series).

I am really missing a comment from the developers here. This is a data loss issue!

I used the gconf-editor to turn 'use time-policy' to false as mentioned in
previous comment and the issue was sorted out for me (i.e. no sleeping
automatically on battery and not hibernating on critical battery). However
another minor problem is that when it turned to sleep while left unattended
in battery mode, it went to hibernate as soon as I turned it on. Some
configuration must be there to tell hibernate not to count time when in
sleep mode.

FYI, I own a Lenovo 3000V100.

cheers,
Nicolas

On 14/01/2008, Tim <email address hidden> wrote:
>
> I have the same problem.
> Notebook: Asus Z92J (kinda AJ6 series).
>
> I am really missing a comment from the developers here. This is a data
> loss issue!
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https://bugs.launchpad.net/bugs/135548
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Nicos Christodoulou
SciCane Ltd.

The same problem on HP nx8220, Gutsy.

No notifications, no actions, notebook discharges to death, even if I unset "use time for policy".
On feisty everything went perfectly.

Same problem on Lenovo T61, Gutsy Gibbon.

I have all the notifications but no actions are performed by Power Manager. If I try the commands manually they work.

Cheers,
nmtsunami

check earlier comments about gconf-editor changes.

I managed to make it work through that.

chees,
Nicos

On 27/01/2008, nmcaramelo <email address hidden> wrote:
> Same problem on Lenovo T61, Gutsy Gibbon.
>
> I have all the notifications but no actions are performed by Power
> Manager. If I try the commands manually they work.
>
> Cheers,
> nmtsunami
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https://bugs.launchpad.net/bugs/135548
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I also experience this bug, on a Benq Joybook R55.

Unchecking use_time_for_policy did *not* fix this for me.
Raising the time thresholds and checking use_time_for_policy did not either.

I guess confirming the upstream bug ( http://bugzilla.gnome.org/show_bug.cgi?id=506305 ) would help, if someone here has a gnome bugzilla account.

i have the same problem from gutsy beta until now.
gnome power shows 3 batteries although i have only one and the other two appearing batteries are empty.
so when the battery is low system doesn't suspend as i have set.

system is Compaq Armada E500 laptop with Gutsy latest updates.

appearing to have 3 batteries instead of one

madmetal@madmetal:~$ cat /proc/acpi/battery/C0FF/state
present: no
madmetal@madmetal:~$ cat /proc/acpi/battery/C100/state
present: no
madmetal@madmetal:~$ cat /proc/acpi/battery/C0FE/state
present: yes
capacity state: ok
charging state: charged
present rate: 0 mW
remaining capacity: 43000 mWh
present voltage: 16626 mV

I have the same problem - on an LG T1 Express Dual.

If use_time_for_policy is true it doesn't hibernate before the computer shuts off hard (the power-manager applet runs down to 0% charge and stops showing time estimates before that happends)
Setting use_time_for_policy to false solves the problem.

I have set my system to stand by if power is critical. However, it does nothing, the battery just runs out. I have Hardy Heron, can this be the same bug or should I look elsewhere?

It's the same bug.
This bug have's two problems related, the recognition of the battery status,
it recognizes two or more battery's when you have only one (solved with
Hardy Heron Alpha5 release), and it doesn't trigger any action when the
battery is in critical status (not solved yet).

I hope for a correction as quick as possible.

Best regards,
nmcaramelo

On Fri, Feb 22, 2008 at 10:07 AM, ThomasNovin <email address hidden> wrote:

> I have set my system to stand by if power is critical. However, it does
> nothing, the battery just runs out. I have Hardy Heron, can this be the
> same bug or should I look elsewhere?
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https://bugs.launchpad.net/bugs/135548
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I've written in my duplicate bug that the workaround with use_time_for_policy did not work for me. This was only true before I had rebooted. Now I got notification about low power, critical power and then also a automatic suspend. Wow! :)

good, you always should reboot. linux will let you reboot just the relevant
portion of the system, but only if you know how. Why do you want it to
suspend on low power? It will just continue to draw power in suspend mode.
It'll then turn off without shutting down properly. I'd rather set the
limits lower and use hibernate mode. It's not like the computer can do
anything useful while suspended. I pretty much never use suspend because it
stops downloads.

On Sun, Feb 24, 2008 at 11:49 AM, ThomasNovin <email address hidden> wrote:

> I've written in my duplicate bug that the workaround with
> use_time_for_policy did not work for me. This was only true before I had
> rebooted. Now I got notification about low power, critical power and
> then also a automatic suspend. Wow! :)
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https://bugs.launchpad.net/bugs/135548
> You received this bug notification because you are a direct subscriber
> of the bug.
>

The same kind of errors are coming back in hardy: bug #194719 and gutsy: bug #154003
Although they're not exactly the same they reporters are complaining about double batteries. Could it have the same cause?

Using Inrepid I still have the problem on a Thinkpad T43 (g-p-m version is 2.24.0-0ubuntu8). I think the problem is, that g-p-m recalculates remaining time and percentage only if battery changes by 1%. Let me explain this:

- Reading /proc/acpi/battery/BAT0/state my Thinkpad T43 battery discharges very regulary (10-40 mWh / sec steps) until it reaches the alarm-capacity of 2206mWh (/proc/acpi/battery/BAT0/alarm) - from no on the state doesn't change anymore for some time and remains at about 1800 mWh. This represents about 4% remaining capacity (shown by left-click on g-p-m applet).

- Now g-p-m only recalculates if battery changes by 1% no recalculation happens for that time. As 4% is calculated to 10-15 minutes remaining time no automatic shutdown is triggered, no matter if use_time_for_policy is true or false, as both thresholds are much lower (2% or 120 seconds).

- Near complete crash of the system the battery state begins to change again, but drops from 1800 mWh to near ZERO. The remaining time is not enough to let g-p-m trigger anything and the system crashes.

Suggestions: raise all thresholds or change the way g-p-m is polling or beeing notified about battery state changes.

Addendum: things seem to be more complicated.

Using "use_time_for_prolicy" I cannot manage to make my system shutdown automatically, even with 360-seconds as power-off treshold. This should work, as when my laptop battery reaches 3% the calculated remaining time drops to 5-minutes (300sec < 360), but nothing happens.

Disabling "use_time_for_prolicy" and raising up corresponding theshold seems to work better.

Generally there is additionally a problem when my battery suddenly dropps from 3% to 0% directly. In this case g-p-m does not react to this change and again noting happens. So if 3% was calculated to 5 minutes remaining time than jumping to 0% directly g-p-m still shows 5 minutes remaining time.

Tested in Ubuntu Intrepid - not working!

also still problem on Intrepid with Asus Z99H

Same problem on a NEC P550. I hope changing the GConf-value helps.

I can confirm the regression on my ubuntu up-to-date 8.10 64bit on a dell xps m1330.
I can also confimrm the behaviour described by arturj in comment 104. For me as well raising the critical action threshold to at least 360 seconds was working as a workaround in ubuntu 8.04.

No bios updates happend in the mean time.

Yesterday the Gnome Power tool warned me that I had 1 minute remaining. Although a 1 minute warning is useless, it at least seems to be warning me now.

8.10 with proposed updates
Dell Inspiron 8600

this is very bad:

i got it too!
Sony VAIO FZ31M, ubuntu intrepid

the first time, after installation it worked automatically; gpm warned me and 1min later hibernated as set.
i was so happy, the first time it ever worked out of the box.
so i never thought about it anymore.. BUT since then it never worked again, meaning, i am trusting the gpm to do his job and suddenly, BUZZ laptop dead.

since then i tried gconf-manager, changing settings like mentioned above, but nothing works.
what works is the warning "you have one minute remaining before hibernation" and after 5min BUZZ dead.

in Hardy i helped myself by adjustin laptop-mode.conf, but those options are gone in Intrepid!
what can we do?

> gpm warned me and 1min later hibernated as set.

Well this is a problem on its own. One minute is not nearly enough. Should we file a separate bug about this? Where is the 1 minute limit determined?

wow, it worked for me (still don't believe it, maybe recent updates helped)
the LCD was in "off" mode, and the Totem and Vlc were playing parallely
(well after resume I have sound problems, but that's differnent story)

(Asus laptop Z99H -- 82801G (ICH7 Family))

I'm using ubuntu 8.10 and I did this to solve the problem:

On Configuration Editor (gconf-editor)
I've set the followed keys:
/apps/gnome-power-manager/general/use_time_for_policy (false)
/apps/gnome-power-manager/thresholds/percentage_low (15)
/apps/gnome-power-manager/thresholds/percentage_critical (12)
/apps/gnome-power-manager/thresholds/percentage_action (10)
/apps/gnome-power-manager/actions/critical_battery (hibernate)

This means that when my battery reaches 15% GPM will show a "low battery warning", at 12% it will show a "Critical battery warning" and at 10% it will put my system to hibernate. I have a li-ion battery and use 10% to prevent damage to it.

I think that there should be a way to set these values directly on GPM, not just via gconf-editor

The configuration of which pruch wrote solve the problem in Hardy too.

I spoke to quickly. In fact, after having set the "pruch" configuration, today the system automatically went into shutdown (and this is ok) but without warning about the remaining battery charge and, moreover, it went into halt at the battery remaining level corresponding to the first warning.

i solved this: i installed kde. it just works.

As there is a partial work-around I'm lowering the priority from Critical to High. Also assigning it to the desktop team where it should be tracked. Ted is no longer on that team.

Could some one experiencing this please give the latest status on updated Jauntu and run 'apport-collect gnome-power-manager' to gather the latest attachments? Thanks!

I happened to go to a near out of battery condition on my EeePC 900 with a recent Jaunty (as of a week ago) and the system correctly suspended to RAM.

this has never worked for me. Started with 8.04 LTS then upgraded to 8.10, then installed 8.10 x86_64. Lenovo Thinkpad R61. I get the warning form gpm that my laptop will be shutdown, but it never shuts down - just dies when power is low. If any logs are required I will provide.

Thinkpad T61. This worked in gutsy and hardy, but not in intrepid and now jaunty. The fancy new status floaty warns at 4 minutes that it will hibernate in 2. 4-5 minutes later the laptop crashes... Manual hibernation works great.

Thinkpad X32. Upgraded-from-Intrepid-to-Jaunty. Gnome Power Manager correctly detects the battery state, correctly issues a "low battery warning" but doesn't initiate hibernation until 0% battery is reached. Additionally, the normal battery light starts flashing orange at the appropriate time...but still no automatic hibernation. What happened? This used to be one of the most reliable and supported laptops *ever*! Manual hibernation and resume still work great.

Which logs do I need to attach to debug this?

Thanks,
Nick

Here are what seem like the relevant logs based on this document:
https://wiki.ubuntu.com/DebuggingGNOMEPowerManager#head-7d2eb767e44a7231fae6964dcf12bc27fe507c9d

Please note that that my laptop *did* successfully hibernate, and return from hibernation from the "gnome-power-cmd hibernate" command.

pruch's solution (https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/135548/comments/113) worked perfectly for me in Ubuntu 8.04 (2.6.24-24-generic) on a ThinkPad X61. However, I do think this is a bug that needs to be addressed, since the average user won't know to use gconf-editor or read through bug reports to fix it.

My laptop does indeed hibernate (or suspend) succesfully, but last night I forgot to plug the AC power and let the laptop on. It didn't hibernate.

The problem, just in case anybody is having it, is that the time profiles are very optimistic in my machine, probably due to the fact that I haven't let the battery drain fully, ever. So, last night GPM thought that there were still time left when in fact the battery was empty.

I wasn't there (but I'm making the test right now) but I'm more or less sure that GPM issued the "low battery" warning because I swear I've seen it at some point in the past. I'm not so sure about the "critical" warning, since it should happen when only 5 minutes of battery remains. Given that the time profile was so optimistic, the laptop probably had the battery empty when GPM thought that there was half an hour left :(((

I don't know if people usually drains their batteries, but if they don't, time profiles are going to be very optimistic. Using time left for taking actions is, in that case, dangerous. Battery percentages should be much safer unless the battery lies about the percentages (which looks like it is very common...).

The solution is to tweak by hand threshold values using gconf-editor and use percentage instead of time left if profiles are way too optimistic.

I'm now carrying a test to see if time left reported by GPM has to do anything with reality in my laptop.

BTW, anybody knows where to go to know how to interpret discharge-time-profiles? I don't understand mine and maybe it explains the wrong behaviour of GPM in my laptop :?

@DervishD: discharge-time-profile tells you the amount of time your laptop spends with a specific battery percentage during a single discharge. For example, in your image, your laptop would quickly discharge from 100 to 90 percent, then slow down from 90-10, then quickly accelerate from 10-0.

Could you test this with a Karmic LiveCD? Sometimes, when upgrading or changing batteries, GPM doesn't keep track of the batteries properly.

Upstream claims that this particular bug has been fixed. Could someone test a clean Karmic system (or LiveCD) to see if your computer will shut down when the battery is critical?

time_critical is set to 5 minutes by default nowadays, which ought to be enough. If you can still reproduce this in current karmic, please do so, reboot, and then

  tar czf /tmp/gpm-log.tar.gz /var/lib/DeviceKit-power

Attach /tmp/gpm-log.tar.gz then. Thanks!

I watched what happens as the battery runs down on my ThinkPad X61. Gnome-power-manager seems to accurately measure the remaining charge until it reaches about 5 percent. After that, it doesn't significantly change. Maybe whatever gpm relies on for its information isn't reporting well…?

If I set the threshold in gconf to 6 percent, hibernation occurs as advertised.

Once again, this is on Ubuntu 9.04 with gpm version 2.24.2-2ubuntu8 and the 2.6.28-13-generic kernel.

+1 On the bug in Jaunty. No action is triggered. A notification is triggered claiming to hibernate/suspend in 1 minute, but nothing happens.

same problem on Acer Aspire 6920G + Ubuntu 9.04 (kernel *.15, AMD64)

In Karmic we changed from hal to devicekit-power. Nobody confirmed that this bug still happens in Karmic, after the call for testing below.

I just tested it myself on my Dell Latitude D430, and I get all the "low"/"critical"/"suspending now" notifications, and the computer suspends when the battery reaches 1.5% charge (it falls back to percentage because it can't estimate the remaining time below 5% any more). I believe g-p-m's policy is correct now. Remaining problems could be that the battery remaining time/percentage is misdetected. This is a hardware specific problem then, and should be reporteded individually against devicekit-power.

Closing now for Karmic (hardy/jaunty are still open, since confirmed several times). Please yell if it still does not work for you in Karmic.

i have a toshiba laptop but when the battery is critical it does not go on hibernate but it just goes off without shutting down or hibernating

live [2009-10-15 18:13 -0000]:
> i have a toshiba laptop but when the battery is critical it does not go
> on hibernate but it just goes off without shutting down or hibernating

Can you please open a new bug with "ubuntu-bug gnome-power-manager"
and do the following:

  killall gnome-power-manager
  gnome-power-manager --verbose 2>&1 | tee ~/gpm.log

then let it drain the battery until it's down to 1% or less (it
regularly shows). Then press ^C, and attach ~/gpm.log to the bug.

Thanks!

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

I still have this bug in Karmic ( on dell vostro 1310 ). I tested 8.10 and 9.10 and this dont works in both.

I have the same bug in Karmic on HP dv4-1120us.

gpm.log is attached.

This bug still occurs in Karmic, even if I set use_time_for_policy to false.

Bug is still appearing in current g-p-m (2.28.1-0ubuntu1) in Karmic.

Maciej Strzelecki [2009-11-12 8:15 -0000]:
> Bug is still appearing in current g-p-m (2.28.1-0ubuntu1) in Karmic.
>
> ** Changed in: gnome-power-manager (Ubuntu Karmic)
> Status: Fix Released => Confirmed

Closing again. This bug report became fairly useless because there
were so many different issues mixed together. Can you please open a
new one with "ubuntu-bug gnome-power-manager" and attach the log?

  killall -9 gnome-power-manager
  gnome-power-manager --no-daemon --verbose >/tmp/gpm.log 2>&1

then reproduce the problem, and attach /tmp/gpm.log to the new bug.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

created a new bug report: 481576
https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/481576

Thank you for taking the time to report this bug. This issue has been fixed in newer versions of Ubuntu, and Jaunty is EOL. Thus, I am closing this bugtask.

Has there been a new bug filed along these lines? I still seem to be running into this in Precise.

To whom it may concern: bug report with similar issue - https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/1096912 - but on 12.10