Description of problem: Using the inhibit command line: systemd-inhibit --what=handle-power-key:handle-suspend-key:handle-lid-switch /usr/bin/mate-power-manager Checking the inhibitors list shows: [william@franky 9:25] /home/william> systemd-inhibit --list WHAT WHO WHY MODE UID PID handle-power-key:handle-suspend-key:handle-lid-switch /usr/bin/mate...bose Unknown reason block 1000 6420 The laptop lid is closed, and suspend begins. Resuming the laptop, the laptop immediately sleeps again. This shows that both mate-power-manager, and systemd initiated a suspend action inspite of the presence of this inhibitor. Checking that this has not crashed on resume shows: [william@franky 10:23] /home/william> systemd-inhibit --list WHAT WHO WHY MODE UID PID handle-power-key:handle-suspend-key:handle-lid-switch /usr/bin/mate...bose Unknown reason block 1000 6420 Note that the PID is the same - The mate-power-manager inhibitor was ignored, despite systemd being told to ignore lid-switch events. How reproducible: Always - I have just repeated this same test numerous times. Resetting the inhibit script has no affect on the outcome. Additional info: There are no crashes reported by abrt. No errors in /var/log/messages. No denials in audit.log. No errors in journalctl.
This is still ongoing.
Still no communication about this, and the issue is still present.
If you open a terminal and run "systemd-inhibit --what=handle-power-key:handle-suspend-key:handle-lid-switch sleep 999999", and then open a second terminal and run "journalctl -u systemd-logind.service -f" and then suspend while that is running: what happens? still the double suspend? What do you see in the journalctl output? (please attach...)
You haven't mentioned which agent is doing the suspending here, and which mechanism it is using. Inhibiting systemd will only be effective if you are suspending via logind. If your desktop environment is e.g. calling out to pm-utils, it won't help.
I am using mate-power-manager, which in turn uses pm-utils. Jan 08 10:22:46 franky.firstyear.id.au systemd-logind[692]: Lid closed. Jan 08 10:22:58 franky.firstyear.id.au systemd-logind[692]: Suspending... Jan 08 10:22:58 franky.firstyear.id.au systemd-logind[692]: Lid opened. WHAT WHO WHY MODE UID PID handle-power-key:handle-suspend-key:handle-lid-switch william Mate power ma...ents block 1000 2261 1 inhibitors listed. If I run Lennart's command along side mate-power-manager, I get: Jan 08 10:26:46 franky.firstyear.id.au systemd-logind[692]: Lid closed. Jan 08 10:26:57 franky.firstyear.id.au systemd-logind[692]: Suspending... Jan 08 10:26:57 franky.firstyear.id.au systemd-logind[692]: Lid opened. WHAT WHO WHY MODE UID PID handle-power-key:handle-suspend-key:handle-lid-switch william Mate power ma...ents block 1000 2261 handle-power-key:handle-suspend-key:handle-lid-switch sleep 999999 Unknown reason block 1000 2807 2 inhibitors listed. And the same double sleep. Of course, running with mate-power-manager disabled, and the systemd-inhibit command as provided, does not cause the laptop to sleep. I was under the impression that inhibiting systemd, was to prevent systemd from making power management decisions and delegating this to another system.
OK, i geuss mate should be updated then to use logind for suspending, the way upower/g-p-m already do. Reassigning to mate.
MPM already has a patch for this in Fedora. Unfortunately, it is still using a lot of the old 2.x code. Hopefully it will get fixed upstream soon.
Reassigning to systemd. Changing the following in /etc/systemd/logind.conf: === HandlePowerKey=ignore HandleSuspendKey=ignore HandleHibernateKey=ignore HandleLidSwitch=ignore === Seems to fix the problem for me. Seems more like systemd/upower problem to me, Lennart. Please correct me if I'm wrong and if I am wrong could you please fix this in systemd upstream or provide some type of patch for mate-power-manager? "It works with Gnome 3" is not good enough. Other DE's are experiencing this issue as well.
Well, it's the mate maintainer's job to make sure their packages work fine with Fedora, not mine. They decided to fork GNOME, so the onus is on them to port the improvements over. I don't run mate, I can't really debug this. Has anybody checked what code actually is responsible for the second suspend? Have you tried adding logging to the "pm-suspend" script? Maybe something still invokes that. Or consider adding an "exit 0" to it. If it doesn, then you just need to figure out which service invokes that.
I see nothing to fix in systemd here. Closing. Feel free to reopen if there's actually a bug in systemd here.
I'm guessing mate-power-manager is hitting the same thing we did in kde. using suspend functionality via upower seems to be racy, and it all-too-often double-suspends.
If so consider opening a bug in upower!
OK, reassigning, adjusting summary to: upower-requested suspend actions seem to ignore systemd inhibitors
https://github.com/mate-desktop/mate-power-manager/pull/55 "With upower 0.9.20, sleep and hybernate functions of upower declared deprecated. All applications should use logind for sleep/hybernate."
Except f18 (currently) ships upower-0.9.19-1.fc18
Regardless, it seems that this patch bypasses upower completely, and the problem is solved.
I assume by "this patch" you mean the mate-power-manager patch? Sure, problem is avoided for *you*, perhaps, but not other users of upower-for-suspend, like xfce.
Yes. Maybe you could port to other power managers it since the upower maintainer seems to be unresponsive...
I have. In particular, xfce maintainers (so far) have been unwilling to include/port to anything < f19
That is unfortunate.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.