Description of problem: The power action of acpid checks if a power manager is running. Among the checks the "xfce4-power-manager" is missing, resulting in acpid to shutdown the PC immediately, if the power button is pressed. ... ps axo uid,cmd | \ awk ' $1 == '$uid_session' && ($2 ~ /gnome-power-manager/ || $2 ~ /kpowersave/ || $2 ~ /kded4/ || $3 ~ /guidance-power-manager/) \ { found = 1; exit } END { exit !found } ' || shutdown -h now ... Version-Release number of selected component (if applicable): acpid-2.0.9-4.fc15.i686 How reproducible: Always Steps to Reproduce: 1. Install and run acpid 2. Install and run xfce4 with power manager 3. Press the power button Actual results: PC shuts down immediately without warning Expected results: The xfce4 power manager should take over and do whatever it was told to do. Additional info: Not sure what happens if more than one power manager is running. Usually, from xfce4, it is possible to run GNOME things, like the power manager, for example.
Created attachment 529694 [details] patched power.sh It seems to be a matter of adding a single clause to an awk condition of not initiating shutdown.
This is also affecting GNOME, now, because gnome-power-manager doesn't exist any more: gnome-settings-daemon handles this stuff. power.sh looks for gnome-power-manager. acpid is still default in comps, though it's taken out of the desktop live image in spin-kickstarts. So the result of this bug is that when you hit the power button in Xfce or GNOME, with acpid installed, the system just shuts down instead of letting the desktop handle the action.
Hi all, I think the real bug is in the different desktop power managers. They should interface with acpid in order to handle the ACPI things, but they don't, they skip the proper layering and try to solve the issue by themselves, instead of using a centralized solution. Saying it differently, is not acpid that should look for the xyz-power-manager, but the opposite, the power manager in charge should look for acpid. Anyway, I'm almost sure the developers of the different desktop environment will never accept that... Sorry for the rant, but I'm getting a bit tired of this "desktop does all" approach... bye, pg
I'm not sure you're going to get a lot of traction with that argument, given that the Fedora desktop team's solution to 'acpid interferes with stuff' was to drop acpid from the desktop live image.
As I wrote, I'm, instead, quite sure it will *not* be accepted... :-) It should at least be possible to start/stop acpid depending on the run level, maybe this could be the solution. On run level 5, acpid should be stopped, level 3 should run. It is not the correct solution, but it could work for all. Should still complain about the general architecture... bye, pg
acpid-2.0.14-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/acpid-2.0.14-1.fc16
acpid-2.0.14-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/acpid-2.0.14-1.fc15
Package acpid-2.0.14-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing acpid-2.0.14-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0019/acpid-2.0.14-1.fc16 then log in and leave karma (feedback).
acpid-2.0.14-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
acpid-2.0.14-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.