Bug 841811 - RFE: redirect ACPI power/sleep button presses to other actions
RFE: redirect ACPI power/sleep button presses to other actions
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Václav Pavlín
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-20 05:31 EDT by hramrach
Modified: 2012-10-08 08:22 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-07 18:37:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description hramrach 2012-07-20 05:31:09 EDT
Description of problem:

I am not running gnome nor kde.

When I press the power button nothing heppens.


Steps to Reproduce:

1. run a session without power manager (eg. a stanadalone WM)
2. press the power button
  
Actual results:

-


Expected results:

something happens

Additional info:

I guess the acpid should be installed by default and in absence of a power manager should print some nice informational message in the log that it should be configured to do something.

Powering off is another option but being conservative here and just printing a message seems more appropriate.
Comment 1 Bill Nottingham 2012-07-20 11:19:58 EDT
This is fixed in rawhide systemd - if no session is active, it will handle the power button and power off.

(Doing it when a session is active seems wrong.)
Comment 2 hramrach 2012-07-24 06:55:59 EDT
The solution in rawhide systemd is unsatisfactory.

AFAICT it invokes the shutdown target directly and there is no way to change the action other than recompiling systemd.
Comment 3 Michal Schmidt 2012-07-24 09:28:52 EDT
You can disable the handling of the power button by systemd-logind in /etc/systemd/logind.conf, HandlePowerKey. Then you can use acpid or similar tools to react to the button. I do not think it's important for logind to allow arbitrary configurable actions.

On the other hand, simply adding one level of indirection would add sufficient flexibility. Instead of launching poweroff.target directly, logind could launch power-button.target. By default this would be a symlink to poweroff.target, but it could be overridden.
Comment 4 hramrach 2012-07-24 09:55:06 EDT
disabling handling in systemd and then installing another daemon only adds issues and is not a solution.

if systemd is to handle power button then it should have distinst poweroff and power button targets.
Comment 5 Michal Schmidt 2012-07-24 11:35:22 EDT
As I described in comment #3, adding the distinct targets should be easy:
 - Create the symlinks at an appropriate place in Makefile.am.
 - Use the new targets instead of SPECIAL_POWEROFF_TARGET etc.
   in src/login/logind-button.c.

[ I think this would be a good BZ for Václav to take. Reassigning to him :-)
  Václav, let me know if you need help. ]
Comment 6 Lennart Poettering 2012-08-08 19:47:27 EDT
We probably should have power-key.target and sleep-key.target which by default point to poweroff.target resp. suspend.target but can be redirected as needed. Not sure though if we want this for lid-switch.target as well... Given that that is not a generic key but very specific it might make sense to leave that directed directly to suspend.target. Or maybe not, dunnoi.
Comment 7 Lennart Poettering 2012-08-09 11:24:10 EDT
Hnmm, so i think this might actually be harder than I initially thought.

logind after all does all this inhibition logic. That inhibition logic works differently if the action we are about to take is suspend, hibernate, poweroff, reboot. Hence which operation to execute must be known to logind, and just doing this via symlinks is not sufficient.
Comment 8 Václav Pavlín 2012-08-13 03:33:50 EDT
What inhibition logic do you mean? As I looked through the code, everything seems to be the same for all actions. The only difference I see, is function called to process the pushed key (button_power_off, or button_suspend), which is just to cover logind.conf settings. Everything else is done by the started unit. Or, maybe, I am missing something.
Comment 9 Lennart Poettering 2012-08-14 11:33:39 EDT
The manager_is_inhibited() calls you find in src/login/logind-button.c need to know what action is suppsoed to be executed. I am mostly concerned about thise. If we do the redirection outside of logind, they can't follow the right inhibitors....

My guess is that we should probably extend the HandlePowerKey=, HandleSleepKey=, HandleLidSwitch= settings to be useful to override what happens. Currently they are booleans. Maybe we can build on that: if they parse as booleans then the right thing for the respective setting happens. If they don't parse as booleans we could check them against "poweroff", "reboot", "halt", "kexec", "suspend", "hibernate" and then redirect things as needed. 

Hence:

HandleSleepKey=no        ; turns off sleep key handling
HandleSleepKey=1         ; sleep key = suspend the machine (the default)
HandleSleepKey=hibernate ; sleep key = hibernate the machine

Or something like that. This way we encode quite nicely what the default is supposed to be, we don't have an inflation of settings, are compatible with the current logic, but allow people to redirect things as they need.
Comment 10 Václav Pavlín 2012-08-15 06:39:26 EDT
(In reply to comment #9)
> The manager_is_inhibited() calls you find in src/login/logind-button.c need
> to know what action is suppsoed to be executed. I am mostly concerned about
> thise. If we do the redirection outside of logind, they can't follow the
> right inhibitors....

Ok, I see, my mistake.

> 
> My guess is that we should probably extend the HandlePowerKey=,
> HandleSleepKey=, HandleLidSwitch= settings to be useful to override what
> happens. Currently they are booleans. 

With respect to the logind.conf man page, those settings are not booleans. They can be one of off, no-session, tty-session, any-session and always, thus they have completely different meaning than in your comment.
Comment 11 Lennart Poettering 2012-09-13 15:37:01 EDT
(In reply to comment #10)

> > My guess is that we should probably extend the HandlePowerKey=,
> > HandleSleepKey=, HandleLidSwitch= settings to be useful to override what
> > happens. Currently they are booleans. 
> 
> With respect to the logind.conf man page, those settings are not booleans.
> They can be one of off, no-session, tty-session, any-session and always,
> thus they have completely different meaning than in your comment.

Ah, ouch. Then I guess we should add RemapSleepKey=, RemapLidSwitch=, RemapPowerKey= or so which could be used to remap the actions normally taken. They each would take an enum: reboot|poweroff|halt|kexec|suspend|hibernate.
Comment 12 hramrach 2012-09-14 10:59:50 EDT
Why has it to be this hardwired?

With acpid there was a default script for power button (which is presumably now the default in systemd too) which would check for running X11 user session and invoke the power manager in there and failing that shut down the system.

When you wanted to customize the power button action you simply replaced the script with anything you wanted. Yes, not a fixed choice, anything. Especially useful for the lid switch if you wanted it to do something useful.

Now in systemd the power switch is hardwired to perform the shutdown action so if you cutomize it you lose the ability to shut down the system. Awesome, eh?

The situation with the lid switch is obviously similar. Otherwise it would not sneak into this bug.
Comment 13 Lennart Poettering 2012-09-14 12:48:04 EDT
(In reply to comment #12)
> Why has it to be this hardwired?

It doesn't have to. You can always redirect suspend.target or poweroff.target to whatever you want.
 
> With acpid there was a default script for power button (which is presumably
> now the default in systemd too) which would check for running X11 user
> session and invoke the power manager in there and failing that shut down the
> system.

Well, this is quite backwards, as it should never be the system the queries user stuff but user stuff that listens to system events. This is properly implemented in GNOME these days.

> Now in systemd the power switch is hardwired to perform the shutdown action
> so if you cutomize it you lose the ability to shut down the system. Awesome,
> eh?

You can redirect things on the low-level anyway, and this but is a feature request to allow remapping it more high-level, too. So not sure what you want. We are just adding more options on all levels so that you can shoot yourself in the foot! ;-)
Comment 14 hramrach 2012-09-14 13:02:40 EDT
I want the power button to suspend the system regerdless of the DE running (usually none).

The power button is handled by systemd wihch wires it to the poweroff.target which is also used by the poweroff command afaik so if you change it you lose the ability to poweroff.

Now for power button the choice from reboot|poweroff|halt|kexec|suspend|hibernate is not oveerly limiting but for the lid switch it is not unreasonable to want xscreensaver to lock the screen. How do you do that with that choice?
Comment 15 Fedora Update System 2012-09-25 19:07:17 EDT
glibc-2.16-17.fc18, systemd-192-1.fc18, selinux-policy-3.11.1-23.fc18, rtkit-0.11-3.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/selinux-policy-3.11.1-23.fc18,rtkit-0.11-3.fc18,systemd-192-1.fc18,glibc-2.16-17.fc18
Comment 16 Fedora Update System 2012-09-27 20:14:26 EDT
Package glibc-2.16-17.fc18, systemd-192-1.fc18, selinux-policy-3.11.1-23.fc18, rtkit-0.11-3.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.16-17.fc18 systemd-192-1.fc18 selinux-policy-3.11.1-23.fc18 rtkit-0.11-3.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/selinux-policy-3.11.1-23.fc18,rtkit-0.11-3.fc18,systemd-192-1.fc18,glibc-2.16-17.fc18
then log in and leave karma (feedback).
Comment 17 Fedora Update System 2012-10-01 16:04:35 EDT
Package glibc-2.16-17.fc18, rtkit-0.11-3.fc18, systemd-193-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.16-17.fc18 rtkit-0.11-3.fc18 systemd-193-1.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/rtkit-0.11-3.fc18,systemd-193-1.fc18,glibc-2.16-17.fc18
then log in and leave karma (feedback).
Comment 18 hramrach 2012-10-08 08:22:52 EDT
Tried Fedora 18 Aplpha live CD but it contains systemd 188-3 which does not seem to contain any of these updates.

Note You need to log in before you can comment on or make changes to this bug.