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.
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.)
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.
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.
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.
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. ]
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.
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.
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.
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.
(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.
(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.
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.
(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! ;-)
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?
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
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).
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).
Tried Fedora 18 Aplpha live CD but it contains systemd 188-3 which does not seem to contain any of these updates.