Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#29974 - [pm-utils] pm-powersave script not working properly

Attached to Project: Arch Linux
Opened by Federico (nierro) - Tuesday, 22 May 2012, 12:53 GMT
Last edited by Andreas Radke (AndyRTR) - Friday, 01 June 2012, 05:44 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Architecture i686
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


Description: Pm-utils powersave functions seem to not understand properly what is the state of my machine, after suspend / hibernation: it randomly thinks i'm on ac even if i'm on battery.
I'm using xfce 4.10 (but i set power manager up not to touch my config, so i do not use the two options in xfce-power-manager -> battery -> "slow down hard disks" and "prefer energy saving instead of performance".
I only use a pm-powersave script that i created and put in /etc/pm/power.d/.
I noticed that there's an hook in /usr/lib/pm-utils/sleep.d/00powersave, that put my netbook in ac state before suspend/hibernation and then run pm-powersave again, during wake up. But, as i said, it seems to randomly run pm-powersave twice, may be at the same time, and so it understands my state wrongly.

Additional info:
* package version(s): pm-utils 1.4.1-4, xfce4-power-manager 1.2.0-2 and upower 0.9.16-1
I don't know what log files to attach, because i don't know how to debug properly.

Steps to reproduce:
Hibernate / suspend some times in a row and then in my pm-powersave.log i'll see that last call to pm-powersave is "false" state.
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Friday, 01 June 2012, 05:44 GMT
Reason for closing:  None
Comment by Federico (nierro) - Tuesday, 22 May 2012, 14:02 GMT
Trying to debug seems that there is something that calls "pm-powersave false" after suspend/hibernation, that is not a script in /usr/lib/pm-utils/sleep.d/ neither a script in /etc/pm/sleep.d/ .
I think it is not xfce4-power-manager..but i can't be sure.
Anyway, i tried to do a pm-suspend after moving /usr/lib/pm-utils/00powersave, so it didn't run, and i found out in my pm-powersave.log that something after resume calls pm-powersave false, but obviously as i said before, no other hooks provide something like this.
EDIT: this is my pm-suspend.log after a suspend in which pm-powersave is set to false: .
And this is its pm-powersave.log : . As you can see, pm-powersave is set to false before suspend, then is set to true, but suddenly something recalls it to false...
EDIT2: tried without running xfce4-power-manager, but the result is the same as above. So it is not xfce4-power-manager related issue.
Comment by Leonid Isaev (lisaev) - Friday, 25 May 2012, 22:48 GMT Comment by Federico (nierro) - Saturday, 26 May 2012, 09:04 GMT
"Fixed in version pm-utils/1.4.1-9". In arch, we're on 1.4.1-5.
So, what can i do for now?
Anyway, the link you posted seems little different from my problem. It is bothering about powersave script that aren't wanted by some users (well, every user i think). Or am i mistaking?
I encountered that problem only after suspend/hibernation. Plugging/unplugging ac makes no errors in my powersave scripts.
Comment by Leonid Isaev (lisaev) - Saturday, 26 May 2012, 16:57 GMT
"-9" is a debian pkgerl -- it doesn't have to concide with arch's.

pm-powersave calls on_ac_power which contains this lop:
# Iterate through power supplies sysfs knows about.
for ps in /sys/class/power_supply/*; do
[ -r "$ps/online" ] || continue
# OK, we know we have an AC adaptor.
# Our default return changes to failed.
read -r ps_status < "$ps/online"
[ 1 -eq "$ps_status" ] && exit 0
It looks into /sys FS for a kernel info about power supplies. If your hardware reports the power state incorrectly/impromptly, there is no way for pm-powersave to guess this state ahead of the kernel. So I suggest you blacklist 00powersave and add your own hook, perhaps pirnting AC/BAT state to a file so you could see what os going on. You can also inspect the output of upower -d to see whether your power devices are properly recognized.

When you use xfce4-power-manager you automatically start upower which calls pm-powersave. That is your mysterious "something".
Comment by Federico (nierro) - Sunday, 27 May 2012, 09:05 GMT
As i said, i tried without xfce4-power-manager too, but the issue had remained(may be if i deactivate it, and then login again, upower remains still on? Have i to reboot?). And for me the mysterious thing is why only after suspend/hibernation? Ie, i thing upower reports my machine state correctly. But after resume, sometimes, i had that issue.
Anyway, i tried with this script in /etc/pm/sleep.d/00powersave:

case $1 in
pm-powersave false ;;
echo "$(upower -d)"
if cat /sys/class/power_supply/AC0/online | grep 0 > /dev/null 2>&1
pm-powersave true
echo on battery!
pm-powersave false
echo on ac!

Obviously that is the right path to check my AC. But the issue is here again. On pm-suspend.log i can see:
Running hook /etc/pm/sleep.d/00powersave resume suspend:

(upower:17101): libupower-glib-WARNING **: Couldn't enumerate devices: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

(upower:17101): UPower-WARNING **: failed to enumerate: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Blacklisting laptop-mode.
Blacklisting hal-cd-polling.
Blacklisting intel-audio-powersave.
Blacklisting journal-commit.
Blacklisting pcie_aspm.
Blacklisting readahead.
Blacklisting sata_alpm.
Blacklisting sched-powersave.
Blacklisting wireless.
Blacklisting xfs_buffer.
on battery!

/etc/pm/sleep.d/00powersave resume suspend: success.

upower -d, after suspend, hangs(may be because the daemon is already called by something else, and then when is ready, returns me: (last part)
daemon-version: 0.9.16
can-suspend: yes
can-hibernate yes
on-battery: yes
on-low-battery: no
lid-is-closed: no
lid-is-present: yes
is-docked: no
So i'm pretty sure upower knows perfectly the state my machine is.
But there are those 2 warnings in my log...
Another thing i noticed is that it takes 5 seconds at least to write the output of upower -d on my log. So i think the issue depends on what makes the last call pm-powersave, if it is my script, then it is ok, but if it is upower, then it calls pm-powersave false, because it can't recognize the state.
Maybe putting a sleep 10 in my 00powersave script could help?
Comment by Federico (nierro) - Sunday, 27 May 2012, 09:55 GMT
tried without xfce4-power-manager, and after reboot, it seems upower is running anyway, i don't know what calls it. And the issue remains anyway.
I was only wondering: after suspend, my script calls pm-powersave. Then pm calls upower to knows the state of machine, right? So what calls upower the second time? xfce4-p-m? Or upower alone tries to understand the state, without any purpose?
Thanks, and sorry for the very long former post.
Comment by Leonid Isaev (lisaev) - Sunday, 27 May 2012, 17:12 GMT
> echo "$(upower -d)"

This is a problem because of two reasons: (1) When you start xfce4 (and the power manager) or bring up the logout dialog, xfce4-session makes a dbus call which starts upower (which is still running after you logout). Then upower -> pm-suspend -> 00powersave -> upower-d == upower blocks -- bad. (2) Which tty do you plan to echo to? You have to redirect to a file.

> So i'm pretty sure upower knows perfectly the state my machine is.

After you resume, as a normal user from a terminal call upower -d... there's no point in speculating. If upowerd is run, it will show something, otherwise, via dbus, upowerd is started and again the command will produce an output. If it hangs then you have a big problem far beoynd pm-itils.

> Then pm calls upower to knows the state of machine, right?

Wrong, see on_ac_power. There was a discussion among pm-utils developers whether one should rely on upower, and the decision was made not to, because upower is a high-level tool while pm-utils is a low-level one. In principle, if you have a proper DE (like gnome or KDE), you shouldn't even know about pm-utils.


Again, see /usr/sbin/pm-powersave script: it just tries to read state of AC/BAT from the kernel. If you think, it does so incorrectly -- this is a bug in pm-utils. Otherwise, you either have a problem with BIOS/kernel or a misconfiguration somewhere.
Comment by Federico (nierro) - Sunday, 27 May 2012, 17:29 GMT
1) > echo "$(upower -d)"
It appears in my log obviously, isn't it correct?
Ok upower is started by xfce4 anyway(when i'm prompted to logout menu too).
2)i'll try and i'll post here the output (i'll remove my script in /etc/pm/sleep.d/ to use the /usr/lib/ one, so i wont block upower during the call of that script.
EDIT: ok, the output is correct, it says i'm on battery. So why there's a "pm-powersave false" call?
EDIT2:As far as i understand /usr/sbin/pm-powersave does the correct thing(that's why running "sudo pm-powersave" in a terminal, without specifically tell it false or true, set correctly my powersave.)
Then my question is, again: where is the problem? Upower reports correctly my state. Pm-utils has no bug. Why i'm having this kind of trouble? The only solution that comes to my mind is to use acpid to have my powersaving set well. But i do not want to use it, because i don't want another daemon doing similar things as userspace software...or do you think acpid would have any advantages?
Sorry again for my lots of questions, but this problem is quite annoying on a laptop (well i only have to use pm-powersave manually after suspend, sometimes; but i find it frustrating).
EDIT3: tried with /etc/Upower/Upower.conf option RunPowersaveCommand=false, and then no problems after resume. But obviously, doing it, means i need acpid to set my powersave script if i plug or unplug ac, plus rc.local to set my script during bootup.
Then i tried moving away /usr/lib/pm-utils/sleep.d/00powersave, and set RunPowersaveCommand to true again in Upower.conf, and after a suspend, i've a call to pm-powersave false. Why false?
I'm really losing my mind there. upower -d says i'm on battery, but put my machine in ac state?
Comment by Federico (nierro) - Sunday, 27 May 2012, 21:27 GMT
wow may be i just found a solution!
What if i put a "killall upowerd" in 00powersave? so, upower won't execute any powersave function, and my problem should be fixed.
Is it right?
I'm only not so sure if i must put it during suspend/hibernation or during resume/thaw.
EDIT: tried by putting killall upowerd during suspend, and pm-powersave works fine. But I 1) don't know how to restart upower as a normal user (not root), tried with this method: . It seems to not work.
That's the script: . Are there any errors?
2) Networkmanager after reusme tells me it is disabled, and i can't figure out why killing upowerd causes this problem. No strange errors in pm-suspend.log.

By the way, i found this: , i think is the same problem i'm having. But it is 2 years old, and it should be fixed...
Comment by Federico (nierro) - Wednesday, 30 May 2012, 13:53 GMT
Well, i finally solved using acpid and in /etc/Upower/Upower.conf toggling false RunPowersaveCommand.
I think this is an issue, may be not related to arch or even pm-utils, and may be neather upower.
Upower after suspend makes a call to run its PowersaveCommand, but the pm-utils script tries to do the same thing. So these two software make the right things, but doing it at the same time causes troubles, as far as i understand.
By the way, this is a big problem for any de which relies on upowerd, and i think it must be fixed (if i understand it correctly, people who doesn't use any de, aren't having any kind of troubles) in any way.
Well, using acpid is may be quite better, because (putting "pm-powersave" in rc.local too) i have powersave management set even if i do not start any de. (with pm-utils and upowerd i had to wait for upowerd to set my powermanagement, but without loading any de, i would not have it set.)
I mark this for closure.
But i hope in a near future this will be fixed. (i noticed this problem only because i have xfce4-cpufreq-plugin, and it was set to performance after suspend; otherwise may be i'll never notice it, and i would be wondering why my battery time decrease without laptop-mode-tools.)