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.