From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510
Description of problem:
When an ordinary user runs /usr/bin/apm --suspend (or --standby) this
operation will fail (with this error: "apm: Operation not permitted").
However apm still returns a 0.
Note that this confuses Gnome's Battery Charge Monitor. It won't give
an error altough the suspend action failed.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. run /usr/binapm --suspend (or --standby) as an ordinary user
2. echo $?
Actual Results: apm: Operation not permitted
Expected Results: apm: Operation not permitted
I'll attach a quick hack which seems to solve this bug.
Created attachment 102149 [details]
a quick hack to end this bug
You can also fix this by installing sudo, use command visudo (as root)
to add the following line to the sudoers file...
%suspenders localhost = NOPASSWD: /usr/bin/apm -s
anyone in the "suspenders" group can execute the following command as
sudo /usr/bin/apm -s
this is useful in interfaces also since the NOPASSWD allows execution
without a password. See...
...for more details.
1) Ryan, thanks for commenting. However, this bug is not about getting
apm to work for ordinary users, but about returning the expected value
(1) when an ordinary user does run apm and causes an error.
2) I noticed that a recent version of Knoppix (3.4) included "apm
version 3.2.1". It has some updates I know of: an actually working
-M/--monitor option and the -M/--monitor option is even mentioned in
the manpage (I haven't checked this bugzilla for those bugs ...).
So it might be that this bug is fixed in apm version 3.2.1: does
anyone know where I can find the Knoppix (= debian?) sources of apm(d)
3.2.1 to check that?
Added in 3.2.2-1 (and it's not fixed upstream, fwiw)