acpid ships with a script which does the following: event=button/power.* 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.
Hello, 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: event=button/power.* 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 Reopening
Two observations 1. If you fix gnome-power-mangler to use a lock file then you can sort the problem trivially 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 desktop session. 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. <annoyed> 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. </annoyed> 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 desktops)
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 http://people.freedesktop.org/~mccann/doc/ConsoleKit/ConsoleKit.html They're also in the ConsoleKit-docs package FWIW.
<chill> I habitually use -mangler for all sorts of things that are -manager, my own code included. That wasn't even done intentionally </chill> 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 gnome-power-manager ?
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 anyone elses.
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.