Bug 789057

tested on up to date factory today, with both GNOME and XFCE and both only suspend one time.

for lid-switch, xfce should probably be started using "systemd-inhibit --what=handle-idle-key "

yes, it is better now (did not try the lid switch again, but forgot my custom inhibit script yesterday and it only suspended once.  Just noticed now ;-)

What does --what=handle-idle-key do, I don't see it documented? 
Shouldn't it rather be 
systemd-inhibit --what=handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch
because all of these are handled by xfce4-power-manager?
More generally, for what reason is the handling enabled by default in openSUSE at all as we didn't handle these events in the acpid default configuration before?
It breaks every power manager not aware of systemd and constitutes a change of default behavior.

@Stefan:
Could you verify the fix in home:gberh:branches:X11:xfce/xfce4-session (using the system xinitrc)? It wraps the call of xfce4-session with "systemd-inhibit --what=idle:handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch" which should work around any systemd interference with events handled by xfce4-power-manager for now.

works fine, xfce4-session is started by systemd-inhibit with apropriate command line options:

seife@susi:~> ps xau|grep inhibit
seife     2967  0.0  0.0  10812   724 ?        S    10:51   0:00 systemd-inhibit --what=idle:handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch xfce4-session

Maybe we could just wrap xfce4-power-manager in systemd-inhibit? Or is something else handling the power button on desktops?
Regardless of that, it is a huge improvement.

Oh, and comment #2 is wrong: without systemd-inhibit, the box now reliably suspended twice per sleep-button press again :-)

(In reply to comment #5)
> Maybe we could just wrap xfce4-power-manager in systemd-inhibit? Or is
> something else handling the power button on desktops?

No, but xfce4-power-manager is a daemon and thus not easily wrapped with systemd-inhibit. Unfortunately xfpm is sort of under-maintained upstream so it's unclear if and when it'll gain native systemd-support.
So I think we have to stick with this rather crude hack in xfce4-session, but ultimately the handling by systemd should be disabled by default in openSUSE like it used to be with acpid.

This is an autogenerated message for OBS integration:
This bug (789057) was mentioned in
https://build.opensuse.org/request/show/150196 Factory / xfce4-session

Guido, I suggest to add this directly after the "test -x /usr/bin/systemd-inhibit..." line:

$SYSTEMD_INHIBIT_CMD true || SYSTEMD_INHIBIT_CMD=

Background: todays update to factory broke permissions so the logged in user is not allowed to systemd-inhibit (I need to file a bug for that).
Even though this is a bug in systemd configuration, I had quite some fun tracking it down and being able to log in again. I would have preferred if just systemd-inhibit would not have worked but at least I would have been able to log in :-)

I have something better, there is now a patch for xfce4-power-manager on the upstream bug. Could you test the xfce4-session and xfce4-power-manager packages from home:gberh:branches:X11:xfce?

I'll do that, once my inhibit problems (bug #789068) are fixed.

(In reply to comment #10)
> I'll do that, once my inhibit problems (bug #789068) are fixed.

Well, this should fix the problem with systemd-inhibit.

I'm not allowed anymore to inhibit, so it will probably not work :-)

(In reply to comment #12)
> I'm not allowed anymore to inhibit, so it will probably not work :-)

You'll be able to login without a workaround though, for inhibiting you need the fixed polkit-default-privs from Base:System.

I don't even remember the exact circumstances of this bug anymore, which means that it is probably fixed in Factory / 13.1 :-)