! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
inhibit systemd from handling buttons and lid events
Status:
RESOLVED: FIXED
Product:
Xfce4-power-manager
Component:
General

Comments

Description Kevin Fenzi 2012-09-26 20:59:40 CEST
This may be marked a dupe of https://bugzilla.xfce.org/show_bug.cgi?id=9326
(This could be handled in xfce4-session by calling systemd-inhibit on session start, but could be solved here by calling the dbus calls to inhibit systemd when xfce4-power-manager is actually running). 

As of systemd version 190, systemd now takes over handling lid button, power and sleep buttons, etc. 
This overrides xfce4-power-manager. It would be nice if xfce4 session could inhibit this on startup. 

From the systemd NEWS file: 

"        * logind's inhibition logic has been updated. By default,
          logind will now handle the lid switch, the power and sleep
          keys all the time, even in graphical sessions. If DEs want
          to handle these events on their own they should take the new
          handle-power-key, handle-sleep-key and handle-lid-switch
          inhibitors during their runtime. A simple way to achiveve
          that is to invoke the DE wrapped in an invocation of:

          systemd-inhibit --what=handle-power-key:handle-sleep-key:handle-lid-switch ..."

See also: http://www.freedesktop.org/wiki/Software/systemd/inhibit

It may be that xfce4-power-manager should take this instead of xfce4-session... which would allow for systemd to handle things still in cases where xfce4-power-manager was not running.
Comment 1 Raphael Groner 2012-10-07 22:13:18 CEST
Kevin,
is it maybe possible to inhibit systemd by a script snippet via xinitrc that calls startxfce4? I guess strongly this should be only a configuration issue.
Comment 2 Kevin Fenzi 2012-10-07 22:56:53 CEST
(In reply to comment #1)
> Kevin,
> is it maybe possible to inhibit systemd by a script snippet via xinitrc that
> calls startxfce4? I guess strongly this should be only a configuration issue.

Yes, but this means that it inhibits it for the entire session. 

So, if for example, you don't have xfce4-power-manager installed, or running, nothing at all will handle the buttons and they won't work. 

It seems cleaner to me to have xfce4-power-manager do this itself, and drop the inhibit on exit. 

Of course it may not be easy to implement, so short term we may want to go with a session wide inhibit in xfce4-session (thus the other bug).
Comment 3 Raphael Groner 2012-10-20 10:17:14 CEST
I can reproduce on Manjaro (ArchLinux). The system is going into standby mode twice, when on power supply, and first to standby, then to hibernation, after woke up from standby.

$ xfconf-query -vl -c xfce4-power-manager
/xfce4-power-manager/brightness-level-on-battery  50
/xfce4-power-manager/brightness-on-ac             120
/xfce4-power-manager/brightness-on-battery        90
/xfce4-power-manager/critical-power-action        1
/xfce4-power-manager/dpms-on-ac-off               11
/xfce4-power-manager/dpms-on-ac-sleep             10
/xfce4-power-manager/hibernate-button-action      2
/xfce4-power-manager/inactivity-on-ac             20
/xfce4-power-manager/inactivity-on-battery        15
/xfce4-power-manager/lid-action-on-ac             1
/xfce4-power-manager/lid-action-on-battery        2
/xfce4-power-manager/power-button-action          3
/xfce4-power-manager/show-tray-icon               2
/xfce4-power-manager/sleep-button-action          1
/xfce4-power-manager/spin-down-on-ac              true
Comment 4 Raphael Groner 2012-10-20 10:18:38 CEST
When on battery, first to standby, then really in hibernation, after woke up from first standby (guess systemd introduces the standby).
Comment 5 Raphael Groner 2012-10-20 16:57:21 CEST
There is "DBus server implementation for org.freedesktop.PowerManagement.Inhibit" available.

see http://git.xfce.org/xfce/xfce4-power-manager/tree/src/xfpm-inhibit.c

Maybe systemd can use that? Sorry, I am not interested in systemd's configuration or internal logic.
Comment 6 Raphael Groner 2012-10-20 17:05:25 CEST
see also bug #9090
"inhibit warning doesn't display application name and reason"
Comment 7 Raphael Groner 2012-12-09 13:01:48 CET
after some discussion has taken place on the mailing lists, this here seems to be more like a feature request. There are options available for the distributions and then also for the end user to work around the unwanted doubled sleep action.

As an alternative to the inhibit option, we could think about an enhancement to the GUI. It could detect that systemd is about handling the switches on a system wide base (generally, only the root user can modify logind.conf while xfpm can have individual settings for each user). When systemd doesn't prevent power management, there should be an hint to the user about that. When the user has chosen "nothing" as the individual action, this doesn't mean systemd cares. The user could get confused in both ways, because there are two independent configurations (root and user). Automated inhibit wouldn't make that less complicated.

I suggest to add a systemd option to all those action handler lists in the settings dialogs. 

For instance, there is a hint already that not enough swap space is available for hibernation. Another hint could also warn about systemd. Improving the user interface make more sense than implementing some magical code behind the possibilites of a not so experienced user.

What do you think?
Comment 8 Konstantin Svist 2013-01-17 23:02:39 CET
My xfce4-power-manager settings explicitly say "do nothing on lid close" -- and yet my laptop started suspending since upgrade to F18.
THIS IS A BUG, NOT A FEATURE. PLEASE FIX ASAP!
Comment 9 Christoph Wickert editbugs 2013-02-13 16:36:52 CET
(In reply to comment #8)
> My xfce4-power-manager settings explicitly say "do nothing on lid close" --
> and yet my laptop started suspending since upgrade to F18.

This can be adjusted in /etc/systemd/logind.conf. Just set HandleLidSwitch and other the events you want to handled by systemd to "ignore".

> THIS IS A BUG, NOT A FEATURE. PLEASE FIX ASAP!

From a x-p-m point of view, support for systemd is a feature.
Comment 10 Mikhail Efremov 2013-02-21 12:54:00 CET
Created attachment 4929 
Don-t-allow-systemd-to-handle-suspend-hibernate-even.patch

Here is patch for inhibiting systemd to handle power/suspend/hibernate buttons
and lid-switch while xfce4-power-manager is running. It works with both systemd and SysV init systems (if there is no systemd-logind then just do nothing).
Comment 11 Kevin Fenzi 2013-02-23 22:24:32 CET
(In reply to comment #10)
> Created attachment 4929 
> Don-t-allow-systemd-to-handle-suspend-hibernate-even.patch
> 
> Here is patch for inhibiting systemd to handle power/suspend/hibernate
> buttons
> and lid-switch while xfce4-power-manager is running. It works with both
> systemd and SysV init systems (if there is no systemd-logind then just do
> nothing).

Patch works fine here for me. :)
Comment 12 god12 2013-06-12 18:10:30 CEST
I think instead of unconditional inhibition user got to have a choice in GUI whether to use systemd settings (this should gray-out x-p-m settings) or override them.
Comment 13 Yves-Alexis Perez editbugs 2013-10-25 10:37:50 CEST
(In reply to god12 from comment #12)
> I think instead of unconditional inhibition user got to have a choice in GUI
> whether to use systemd settings (this should gray-out x-p-m settings) or
> override them.

As far as I understand it, there's also the possibility to only delay the suspend from systemd, in order for xfpm to do something (for example locking the screen). That's what Gnome is doing right now, afaict.
Comment 14 Simon Steinbeiss editbugs 2014-05-29 10:00:57 CEST
This bug has been fixed in git master.

Bug #9335

Reported by:
Kevin Fenzi
Reported on: 2012-09-26
Last modified on: 2014-05-29

People

Assignee:
Ali Abdallah
CC List:
12 users

Version

Attachments

Additional information