After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 467967 - UPS status never changes to low/critical.
UPS status never changes to low/critical.
Status: RESOLVED OBSOLETE
Product: gnome-power-manager
Classification: Deprecated
Component: gnome-power-manager
2.18.x
Other All
: Normal normal
: ---
Assigned To: GNOME Power Manager Maintainer(s)
GNOME Power Manager Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2007-08-18 14:39 UTC by Sioutis Marios
Modified: 2009-03-04 14:37 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18


Attachments
output obtained through several times of gnome-power-bugreport.sh usage (12.17 KB, text/plain)
2007-08-20 13:47 UTC, Sioutis Marios
Details
png screenshot of my settings. (90.83 KB, image/png)
2007-08-20 13:48 UTC, Sioutis Marios
Details
verbose output (218.83 KB, text/plain)
2007-08-29 21:53 UTC, Sioutis Marios
Details
GPM Log critical with nut-hal-drivers using the latest levels patch (3.21 KB, text/plain)
2008-02-14 09:34 UTC, Arnaud Quette
Details

Description Sioutis Marios 2007-08-18 14:39:57 UTC
Please describe the problem:
The UPS status never changes to low or critical, and thus the low/critical actions are never executed.This means that when the ups battery runs out of juice,the pc doesn't shutdown properly.

I know that the ups is considered a "battery" so,I used the gconftool to change the following attributes: 
action_battery_critical = shutdown
battery_percentage_action = 40
battery_percentage_critical = 40
battery_percentage_low = 40
battery percentage_very_low = 40
use_time_for_policy = false
the above values are intended,because when the ups reaches 25% , it cannot further power the pc.

using gnome power preferences i have also set the ups_low / ups_critically low actions to shutdown.

hald does report the status of the ups (correctly or not,the fact that reports it should be enough),thus i assume that the problem lies within the gnome-power-manager.Is there any other configuration that must be done?why doesn't g-p-m notice that the ups battery is below the  critical levels and it doesn't execute the shutdown actions?

I am using debian unstable,using nut-hal-drivers 2.2.0-1,gnome-power-manager 2.18.3-1,dbus1.1.1-3,hal 0.5.9.1-3,all obtained through synaptic.I have added myself as a user to the powerdev group(as suggested by the faq for etch),and also added haldaemon to the nut group (as suggested by the nut-hal-drivers)


Steps to reproduce:
1. cut off power to the computer
2. 
3. 


Actual results:
g-p-m never sets the ups status to low/ critically low, end thus the computer shuts down violently.

Expected results:
the ups status to change to low/critically low and execute the selected action.in this case the selected action is shutdown

Does this happen every time?
yes

Other information:
I have tried this using several values in battery_percentage_action,
battery_percentage_critical,battery_percentage_low,battery percentage_very_low,
ranging from 25 - 45 and nothing happens. in all the above cases the use_time_for_policy was always false.

any ideas?
Comment 1 Richard Hughes 2007-08-19 16:56:20 UTC
>the above values are intended,because when the ups reaches 25% , it cannot
further power the pc.

Why 25% - is the UPS old and the battery needs calibrating?
Comment 2 Sioutis Marios 2007-08-19 20:35:29 UTC
(In reply to comment #1)
> >the above values are intended,because when the ups reaches 25% , it cannot
> further power the pc.
> 
> Why 25% - is the UPS old and the battery needs calibrating?
> 

actually it's a new belkin UPS F6H650yyUNV. The battery has been fully recharged. But ... even if something is wrong with the ups , shouldn't g-p-m power down the computer anyway? I mean,that's why i set the critical action from a  range of values of 25% to 45%, but nothing happens.

I took a look in the source code and tried to grep g_signal_emit CHARGE_LOW but i couldn't figure out the way you calculate when this signal is emitted.I was expecting just a simple comparison between the hal data and the GCONF variables battery_percentage_low battery_percentage_critical, but i think that is not the case.

So, if the battery charge is below the battery_percentage_low(critical) ,why isn't there any status change to low(critical)?
Comment 3 Richard Hughes 2007-08-20 08:43:17 UTC
It should be;

	if (unit->percentage <= warnings->priv->action_percentage) {
		return GPM_WARNINGS_ACTION;
	} else if (unit->percentage <= warnings->priv->critical_percentage) {
		return GPM_WARNINGS_CRITICAL;
	} else if (unit->percentage <= warnings->priv->low_percentage) {
		return GPM_WARNINGS_LOW;
	}

Does lshal (or hal-device-manager) display the UPS percentage correctly? Can you attach the output of gnome-power-bugreport.sh when the UPS is getting low. Many thanks.
Comment 4 Sioutis Marios 2007-08-20 12:25:21 UTC
hal-device-manager reports the same percentage that the gpm reports,I guess this was expected.
about the gnome-power-bugreport.sh i'll try it later in the day and give you  the results!
Comment 5 Sioutis Marios 2007-08-20 13:47:27 UTC
Created attachment 93984 [details]
output obtained through several times of gnome-power-bugreport.sh usage

the first two and the last one data segments are with a/c power backup.
all the middle segments where taken when on ups battery backup
Comment 6 Sioutis Marios 2007-08-20 13:48:48 UTC
Created attachment 93985 [details]
png screenshot of my settings.

the set time for policy is also set on false.
Comment 7 Sioutis Marios 2007-08-22 12:51:30 UTC
any ideas? is it possible that the state change does happen ,but the actions are not executed for other reasons(lack of privileges, misconfigured users/groups )?

Also,please have a look at the previous data provided.I would really like to know if i am the only one that has this problem,or if other users are experiencing it as well.
Comment 8 Richard Hughes 2007-08-22 14:07:51 UTC
It seems everything is in order. Could you run:

killall gnome-power-manager
gnome-power-manager --verbose --no-daemon > log.txt

and let the ups run down to low.

Can you attach the log.txt file please. Thanks.
Comment 9 Sioutis Marios 2007-08-22 14:39:16 UTC
i'll do that but i am leaving on a trip,so i'll need a few days to respond.sometime next monday.
Comment 10 Sioutis Marios 2007-08-29 21:52:05 UTC
here is the output of gnome-power-manager --no-daemon --verbose 2>gpmlog.txt
hope this will be usefull.
Comment 11 Sioutis Marios 2007-08-29 21:53:17 UTC
Created attachment 94578 [details]
verbose output
Comment 12 Sioutis Marios 2007-09-05 03:04:54 UTC
hello , did anybody take a look at this? i posted the requested data....
does anybody have a clue why this is happening?
Comment 13 Sioutis Marios 2007-10-02 20:16:49 UTC
i guess nothing new has popped up.... i'm going to test if this is resolved with gnome 2.20 an an upgraded nut-hal driver package... if anything changes i'll let you know
Comment 14 Arnaud Quette 2008-02-13 14:38:15 UTC
guys,

I'm jumping again on the GPM subject since I'm trying to complete a bit more what is in nut-hal-drivers for the NUT 2.2.2 release.

FYI, previously, the drivers were only exposing battery.low which is sufficient.
Now, I've also computed a bit for battery.warning, though it's not really useful.
I've also prepared some other small fixes...

Now, for the test, I'm also experiencing the same issue (tried on the current Ubuntu 8.04, with GPM 2.21.1)

@Richard: I'm interested in your insight on this.
If needed, I can generated an RPM to make your test easier.
Comment 15 Arnaud Quette 2008-02-14 09:34:05 UTC
Created attachment 105213 [details]
GPM Log critical with nut-hal-drivers using the latest levels patch

what is strange is the "percentage zero, something's gone wrong" since there are log just then "percent        28"

I might be missing something. Though I'm trying to understand how GPM works, there many things I still don't yet see!

@Richard: your GPM knowledges are welcome to complete the UPS support.
Comment 16 Arnaud Quette 2008-02-14 13:23:04 UTC
ok, I think I got the problem (but not yet the root cause of it!).

in src/gpm-warnings.c -> gpm_warnings_get_state_percentage() (which is the function Richard pointed above with:

        if (unit->percentage <= warnings->priv->action_percentage) {
                return GPM_WARNINGS_ACTION;
        } else if (unit->percentage <= warnings->priv->critical_percentage) {
                return GPM_WARNINGS_CRITICAL;
        } else if (unit->percentage <= warnings->priv->low_percentage) {
                return GPM_WARNINGS_LOW;
        }
)

The lines just before are linked to my report "percentage zero, something's gone wrong"):

 if (unit->percentage == 0) {
                /* this is probably an error condition */
                gpm_warning ("percentage zero, something's gone wrong");
                return GPM_WARNINGS_NONE;
        }

So, this explains why Richard's mentioned code isn't executed.
But still not why we got these.
Continuing investigation.
Comment 17 Richard Hughes 2009-03-04 14:37:03 UTC
Thanks for taking the time to report this bug.
However, you are using a version that is too old and not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use.

By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME.
Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME.