pm-utils not working

Lockheed · 2013-06-19 10:54:43

As you said, it didn't work.

nierro · 2013-06-19 17:43:54

Well, i really ran out of ideas...try to report a bug against pm-utils (or whatelse?) on arch bugtracker, may be you'll get better help.

Lockheed · 2013-06-20 07:04:06

It was pointed out to me that

Your script does nothing when $1 is empty.
$1 is a positional parameter set, in this case, by passing an argument to the script. If you pass no argument, your case statement (which appears to be the entirety of the script) will do nothing.

but I don't know how to fix it. The script is a copy of the one from pm-utils Arch wiki so if my script is wrong, so is the original.

nierro · 2013-06-20 07:20:43

Well, pm-powersave functions will call every script in /usr/lib/pm/power.d/ and /etc/pm-utils/power.d with "true" or "false" argument, so that shouldn't be the problem. Have you pointed out you're using pm-utils powersave function?

Lockheed · 2013-06-21 09:34:03

I pointed it out and still waiting for a reply from him.

In the meantime, I was talking with TLP creator on an unrelated matter, and he said something that initially I thought could be the cause of this problem, too

You're running Arch Linux. The Arch implementation of pm-utils does not call pm-powersave before suspend and after resume, so the TLP settings do not get a refresh upon resume (as for example in Fedora which uses systemd too).

but then I remembered that's about sleep.d scripts, not power.d...

Last edited by Lockheed (2013-06-21 09:36:19)

nierro · 2013-06-21 10:17:48

Btw, have you ever think about get rid of pm-utils, acpid and upower, and rely only on systemd and (for the powersave) an udev rule ,or something like powerdown? (you said you're using openbox, and i'm using it too. No pm, no upower, no acpid = less complications, faster suspend/resume cycles, less software installed, less redundance)

This is not a solution obviously, but i think you may "feel" better, and still you won't lose any function. By the way, can you share with me your bug report's link?

Lockheed · 2013-06-21 11:04:01

Yes, I was actually using powerdown-git scripts up until few days ago, when I discovered TLP. I have a ThinkPad so TLP does a lot of things for me that before were much more complicated to achieve.
TLP requires pm-utils, so I had to install it.

Bug report:
https://bugs.archlinux.org/task/35853#comment111396

Lockheed · 2013-06-22 07:28:56

So I got around the problem by creating a udev rule (thanks for the suggestion!).

But is it possible to write a udev rule that would run upon resume from suspend?

nierro · 2013-06-22 10:05:21

I guess you can't...
But I don't understand why you should need that!

Lockheed · 2013-06-22 10:09:15

That's for an unrelated project. I'll use systemd service for that.

Thanks for you help.

BTW: have you ever found a solution of autohibernating the system when battery % is reached?

nierro · 2013-06-22 10:17:48

Uhm...i use my conky for that (with systemd now we don't need root neither upower to hibernate from an active session, so it's enough to "${if_match ${battery_percent BAT0} <= 4}${exec systemctl hibernate}${endif}.
There was also an udev rule to reach that, i don't remember, may be powerconf package (in aur) shipped one. (Btw i don't use it anymore, as i said; instead i use the conky easy way.

Lockheed · 2013-06-22 11:40:09

That's great to know it's doable through conky, but there's a problem with this rule - as far as I can see, it will still hibernate the system even when it is on AC and charging.

nierro · 2013-06-23 09:57:09

With the conky way, you can do:

${if_match "${acpiacadapter AC0}" == "off-line"}${if_match ${battery_percent BAT0} <= 4}${exec systemctl hibernate}${endif}${endif}

With the udev rule you can try to add a

ENV{POWER_SUPPLY_ONLINE}=="0",

right after "SUBSYSTEM=="power_supply" "

Btw can you post here the udev rule?

Lockheed · 2013-06-23 11:15:04

## SLEEP/HIBERNATE IF BATTERY IS LOW
SUBSYSTEM=="power_supply", ATTR{type}=="Battery", ATTR{status}=="Discharging", ATTR{capacity}=="98", RUN+="/usr/bin/systemctl suspend"

It never worked and I think the reason for it is because UDEV does not probe the battery.

nierro · 2013-06-23 11:23:05

Yes, i guess you're right. So...use cbatticon from aur, may be? It allows users to choose an action when on critical battery percent.

Lockheed · 2013-06-23 11:24:21

Nah, your conky rule rules. And is a perfect solution.
Thank you for your help in this thread.

nierro · 2013-06-23 11:27:09

You're welcome

Btw, pm is a mess, i'm looking forward to see it replaced by systemd someway. It aimed to make laptop users' lives easier, but indeed it complicated them.

Arch Linux

#26 2013-06-19 10:54:43

Re: pm-utils not working

#27 2013-06-19 17:43:54

Re: pm-utils not working

#28 2013-06-20 07:04:06

Re: pm-utils not working

#29 2013-06-20 07:20:43

Re: pm-utils not working

#30 2013-06-21 09:34:03

Re: pm-utils not working

#31 2013-06-21 10:17:48

Re: pm-utils not working

#32 2013-06-21 11:04:01

Re: pm-utils not working

#33 2013-06-22 07:28:56

Re: pm-utils not working

#34 2013-06-22 10:05:21

Re: pm-utils not working

#35 2013-06-22 10:09:15

Re: pm-utils not working

#36 2013-06-22 10:17:48

Re: pm-utils not working

#37 2013-06-22 11:40:09

Re: pm-utils not working

#38 2013-06-23 09:57:09

Re: pm-utils not working

#39 2013-06-23 11:15:04

Re: pm-utils not working

#40 2013-06-23 11:23:05

Re: pm-utils not working

#41 2013-06-23 11:24:21

Re: pm-utils not working

#42 2013-06-23 11:27:09

Re: pm-utils not working

Board footer