Seems acpid's /etc/acpi/actions/power.sh no longer functions properly on f17 and kde (at least). It acts unconditionally on power button presses. I'm not sure exactly yet, but I suspect may be related to http://fedoraproject.org/wiki/Features/ckremoval and the script's reliance on ConsoleKit (ck-list-sessions) to check for an active session
OK, found systemd-loginctl which should be able to provide the same information: systemd-loginctl list-sessions and then systemd-loginctl session-status <session_id> will include "Active: yes" or not.
Created attachment 582698 [details] patch acpid.power.sh to use systemd-loginctl too an initial proof of concept patch to check for power managers (gnome-settings-daemon, kded4, xfce4-powermanager) running within active sessions handled by systemd login manager.
ping, someone on kde.org reported experiencing the same thing today. Can you please review the patch? I can commit the fix if you want.
Created attachment 591774 [details] Proposed fix Thanks for the patch. I fixed the xfce4 typo and hide error message in case the systemd-loginctl list-sessions is not available, otherwise it seems to be OK. Another problem is that the list-sessions call is blocked by SELinux thus with SELinux in enforcing mode it still doesn't work. I filled bug about it bug 831977.
Created attachment 591775 [details] Proposed fix Of course removed the debug fragment :)
acpid-2.0.16-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/acpid-2.0.16-2.fc17
Good fixes, I suppose while you're at it, you probably ought to add 2>/dev/null after the later call to ck-list-sessions as well (since there's a good chance it's not installed).
Thanks, I added this to rawhide.
<RANT>And once again we have to get a bugfix copied to the SELinux policy for it to actually work. I'm so fed up of that dumb hardcoded ruleset that keeps thinking it knows better what a program needs to do than the actual program. Now WHY is that software equivalent of nonsensical bureaucracy enabled by default in Fedora?</RANT>
Package acpid-2.0.16-2.fc17: * should fix your issue, * was pushed to the Fedora 17 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.16-2.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-9464/acpid-2.0.16-2.fc17 then log in and leave karma (feedback).
acpid-2.0.16-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
I'm sorry to report that this fixes nothing for me. On an i386 netbook, where suspend and hibernate are important functions, both pm-suspend and pm-hibernate start to shutdown but immediately resume normal operation. The other commands to suspend and hibernate, acpitool -s and acpitool -S both complain that "You must have write access to /proc/acpi/sleep", but there is no such "file". On an x86_64 desktop, where suspend and hibernate are never used, pm-suspend shuts down X and reverts to console 1, but certainly doesn't suspend. pm-hibernate works correctly - Whoop! The acpitool options also fail. The power manager applet also fails on the netbook, although I'm less interested in the GUI methods if the basic Linux commands no longer work.
Your symptoms don't seem to match this bug at all. The bug here is that hitting the power button *used* to get intercepted by acpid and immediately shut the machine off, rather than letting kde handle the power button event.
(In reply to comment #12) > On an i386 netbook, where suspend and hibernate are important functions, > both pm-suspend and pm-hibernate start to shutdown but immediately resume > normal operation. > Try suspend via: # echo mem > /sys/power/state and hibernate: # echo disk > /sys/power/state If this fail, file a bug on kernel component, otherwise file a bug on pm-utils component. > The other commands to suspend and hibernate, acpitool -s > and acpitool -S both complain that "You must have write access to > /proc/acpi/sleep", but there is no such "file". > Please file a bug on acpitool component. In all cases feel free to CC me (it can sometimes speed things up :)
> Try suspend via: > # echo mem > /sys/power/state > and hibernate: > # echo disk > /sys/power/state Jaroslav Škarvada, you are a magician. I don't know what hat you pulled these commands out of, but they work perfectly. I have added two new event files, lidconf and powerconf, to /etc/acpi/events, and corresponding action files containing these echo commands. /etc/acpi/lidconf: event=button/lid* action=/etc/acpi/actions/sleep.sh /etc/acpi/sleepconf: event=button/sleep* action=/etc/acpi/actions/hibernate.sh So now my ASUS N10 netbook with F17 is fully functional again. Sleep button (Fn-F1) causes hibernation Closing the lid suspends to memory Briefly pressing Power Button initiates shutdown Upon wakeup from sleep or hibernation the wireless connection, managed by NetworkManager, starts right up. I'm a happy camper. That pm-sleep and pm-hibernate fail is still a bug, justifying a separate BZ. Also for acpitool [-s|-S]. Thank you.