acpid ships with a script which does the following:
action=/bin/ps awwux | /bin/grep gnome-power-manager | /bin/grep -qv grep || /sb
in/shutdown -h now
Any user running a script of their own called gnome-power-manager left in the
background confuses the script because it checks via ps, not properly by some
kind of pid/lock file check with the power mangler itself.
gnome-power-manager does not create any pid/lock file. So, if we want to use
another way, we have to use D-BUS.
Then the script would look like this:
action=/bin/dbus-send --dest=org.freedesktop.DBus /org/freedesktop/DBus
--print-reply org.freedesktop.DBus.ListNames | grep org.gnome.PowerManager ||
/sbin/shutdown -h now
But anyone can write his own script/application which can have same name (then
ps check will fail) or which can register same name in a d-bus (then dbus check
will fail). Even if a gnome-power-manager used pid/lock file, then anyone would
write application, which would use same pid/lock file too.
So, the question is, what is sufficient control.
A solution with D-BUS is more complicated. The script is ran by root, so one has
to get information about a DBUS_SESSION_BUS_ADDRESS. This variable is stored in
/proc/*/environ, so one has to use ps anyway.
It still needs fixing as its a DoS issue
1. If you fix gnome-power-mangler to use a lock file then you can sort the
2. Failing that the dbus method is still a good one although you'd need a way
to get the dbus session info for the current desktop user.
3. Cleaner still would be for gnome-power-mangler and the button script to
share a named pipe or similar resources
Letting a user *choose* to intercept the power button by dbus or other means is
good, the problem with this bug is I can intercept it when I'm not the live
So I would either fix gnome power manager or wrap it in a bit of code which
writes the pid somewhere then uses exec to run the g-p-m daemon thus giving you
a reliable pid to also match in your grep along with the name.
(In reply to comment #0)
> Any user running a script of their own called gnome-power-manager left in the
> background confuses the script because it checks via ps, not properly by some
> kind of pid/lock file check with the power mangler itself.
Wow, you're so cool calling it mangler instead of manager. Let's all just rant
and use language like that so we can be as cool as Alan.
Now, on a more serious note, keep in mind you may have multiple copies of g-p-m
running; one for each desktop session (this f-u-s etc.). So at least doing pid
files is not going to work...
(Also keep in mind any solution like this should work for kpowersave and other
One way to do this is to check with ConsoleKit whether there are any login
sessions. Probably ck-list-sessions can do this (patches welcome to make it do
what you want); alternatively dbus-send might be another option.
Just for reference, here are the ConsoleKit docs
They're also in the ConsoleKit-docs package FWIW.
I habitually use -mangler for all sorts of things that are -manager, my own code
included. That wasn't even done intentionally
If you hve multiple clients you can do pid files, they just have to hold
multiple entries. ConsoleKit looks perfect here however as it will tell you if
the uid of the supposed 'gnome power manager' matches the current session and
that tells you if the ps return is a real power manager (and a user who has
their own personal gnome-power-manager and is on the console is their own problem).
Not sure if that means you want a "has power manager' for sessions whether k or
I'm not sure, how I'd recognize real g-p-m.
Alan, you wrote that ck tells me the uid of the supposed g-p-m. So when I
execute 'ck-list-sessions', I'll get a list of sessions and I can grep a uid of
active session. (for example 500).
Then I execute 'ps aux' I'll get list of processes in which can be g-p-m and
then I can match uid of active session and uid of g-p-m. That is fine.
But if create a script called g-p-m and I'll execute it, then the uid of this
script will match the uid of active session.
So, I don't see any advantages or improvements if I solve this bug in this way.
Furthermore, as David wrote, we need a solution, which resolve this for any
other desktops, mainly for kde.
If you create a script called g-p-m and you are the desktop active user you can
only mess with your own user experience - maybe even usefully.
If you are not the active desktop it is important you don't get to mess with
Ok, in this point of view, the solution described above is useful.
acpid-1.0.4-9.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
acpid-1.0.6-5.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.