Re: [systemd-devel] diverting HandlePowerKey
Op 16 aug. 2012, om 16:37 heeft Lennart Poettering lenn...@poettering.net het volgende geschreven: On Thu, 16.08.12 14:47, Mantas Mikulėnas (graw...@gmail.com) wrote: On Thu, Aug 16, 2012 at 2:23 PM, Robin Becker ro...@reportlab.com wrote: However, on my netbooks I like to use the power button to launch oblogout which brings up a bunch of buttons that allow me to logout/suspend/restart/halt etc etc. I can of course continue to use acpid to handle the power button, but that seems opposed to the spirit of systemd. acpid is still okay, I believe. Even though it comes with a single shell script for all actions, it is not part of boot process, and it's not a required part of acpid either – acpid actually has a built-in filtering mechanism in /etc/acpi/events, and the shell script is just default configuration. However, running X11 programs from a daemon, regardless whether it it is logind or acpid, is not recommended. Sure, it might be okay for a single-user machine, but I have ended up with two, three X servers fairly often even on my personal laptop. It'd be a bit better if the button/lid events were handled by a program running inside the Openbox session (the events can be read from /run/acpid.socket). No, nobody should use the acpid client protocol for this. On Linux ACPI key presses are processed like any other keys, and thus are propagated to the X server. The desktop environment should handle these keys and then do whatever is necessary (show a dialog box, react immediatey, ...). And ACPI is x86 only, so you should really focus on catching the KEY_POWER event ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] diverting HandlePowerKey
On 16/08/2012 18:36, Lennart Poettering wrote: .. Invoke the PowerOff() call on the org.freedesktop.login1.Manager interface of the /org/freedesktop/login1 object on the org.freedesktop.login1 service. Which is basically what systemctl poweroff does. thanks for this. I think my route to doing everything via openbox is a bit stymied as I cannot seem to get the lid switch to generate a keypress, even showkey says nothing going on. -- Robin Becker ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] diverting HandlePowerKey
Hi, I liked the idea of systemd when I first saw it, but after doing a few conversions I have some small issues. I run arch linux with slim openbox and that seems to be fully supported so far as I can tell. However, on my netbooks I like to use the power button to launch oblogout which brings up a bunch of buttons that allow me to logout/suspend/restart/halt etc etc. I can of course continue to use acpid to handle the power button, but that seems opposed to the spirit of systemd. Is there a way to divert HandlePowerKey to a script of my choosing? I could imagine that an option starting with a / character could be used to distinguish such a command from one of the standard logind.conf values, but that's obviously not implemented. Even if it was does systemd allow me to configure oblogout properly ie check for the conditions no-session, tty-session, any-session? Shell scripts might be a bit slower at boot, but they allow for possibilities that were not thought of at design time. Of course I would also like to treat the lid switch in a different way to what systemd proposes, surely it's obvious that some might like to hibernate or power off rather than suspend if the lid is closed? -- Robin Becker ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] diverting HandlePowerKey
On Thu, Aug 16, 2012 at 2:23 PM, Robin Becker ro...@reportlab.com wrote: However, on my netbooks I like to use the power button to launch oblogout which brings up a bunch of buttons that allow me to logout/suspend/restart/halt etc etc. I can of course continue to use acpid to handle the power button, but that seems opposed to the spirit of systemd. acpid is still okay, I believe. Even though it comes with a single shell script for all actions, it is not part of boot process, and it's not a required part of acpid either – acpid actually has a built-in filtering mechanism in /etc/acpi/events, and the shell script is just default configuration. However, running X11 programs from a daemon, regardless whether it it is logind or acpid, is not recommended. Sure, it might be okay for a single-user machine, but I have ended up with two, three X servers fairly often even on my personal laptop. It'd be a bit better if the button/lid events were handled by a program running inside the Openbox session (the events can be read from /run/acpid.socket). -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] diverting HandlePowerKey
On 16/08/2012 12:47, Mantas Mikulėnas wrote: On Thu, Aug 16, 2012 at 2:23 PM, Robin Becker ro...@reportlab.com wrote: It'd be a bit better if the button/lid events were handled by a program running inside the Openbox session (the events can be read from /run/acpid.socket). I'm not exactly sure here, but aren't the standard power events in systemd handled by a daemon running outside openbox? I thought that the handler kinds eg no-session, tty-session, any-session were supposed to allow some control over whether I can switch off the machine with other users logged on etc etc. Perhaps with cgroups those sorts of capabilities can be passed on to another program. Openbox is actually running as a user process so it has no greater rights than the user; that makes the use of a more capable daemon a bit more reasonable. -- Robin Becker ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] diverting HandlePowerKey
... Openbox is actually running as a user process so it has no greater rights than the user; that makes the use of a more capable daemon a bit more reasonable. No, if your action just runs `oblogout` (and possibly `systemctl suspend`), then the capabilities of a normal user are sufficient. Mantas, I think you are right that openbox can call oblogout, but my existing oblogout is trying to call shutdown, halt, hibernate etc etc and aren't those the things that HandlePowerKey is supposed to protect? I suppose there are dbus messages that can be used with consolekit, but that's just the more capable daemon again. Currently my oblogout is doing nasty things like sudo shutdown ie it gives itself super powers in a rather brutal way. -- Robin Becker ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] diverting HandlePowerKey
On Thu, 16.08.12 12:23, Robin Becker (ro...@reportlab.com) wrote: Hi, I liked the idea of systemd when I first saw it, but after doing a few conversions I have some small issues. I run arch linux with slim openbox and that seems to be fully supported so far as I can tell. However, on my netbooks I like to use the power button to launch oblogout which brings up a bunch of buttons that allow me to logout/suspend/restart/halt etc etc. I can of course continue to use acpid to handle the power button, but that seems opposed to the spirit of systemd. I don't get this. This oblogout thing is a graphical tool you spawn from the system level? Does that mean it runs privileged but accesses your unprivileged X session? That sounds wrong... If you have a graphical session then the graphical session should handle the power/sleep key presses directly. Is there a way to divert HandlePowerKey to a script of my choosing? No, there currently isn't. Eventually might add something that would allow people to reconfigure what happens when people press the power/sleep keys. But I am not sure we'll allow specification of arbitrary scripts for that. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] diverting HandlePowerKey
On Thu, 16.08.12 14:47, Mantas Mikulėnas (graw...@gmail.com) wrote: On Thu, Aug 16, 2012 at 2:23 PM, Robin Becker ro...@reportlab.com wrote: However, on my netbooks I like to use the power button to launch oblogout which brings up a bunch of buttons that allow me to logout/suspend/restart/halt etc etc. I can of course continue to use acpid to handle the power button, but that seems opposed to the spirit of systemd. acpid is still okay, I believe. Even though it comes with a single shell script for all actions, it is not part of boot process, and it's not a required part of acpid either – acpid actually has a built-in filtering mechanism in /etc/acpi/events, and the shell script is just default configuration. However, running X11 programs from a daemon, regardless whether it it is logind or acpid, is not recommended. Sure, it might be okay for a single-user machine, but I have ended up with two, three X servers fairly often even on my personal laptop. It'd be a bit better if the button/lid events were handled by a program running inside the Openbox session (the events can be read from /run/acpid.socket). No, nobody should use the acpid client protocol for this. On Linux ACPI key presses are processed like any other keys, and thus are propagated to the X server. The desktop environment should handle these keys and then do whatever is necessary (show a dialog box, react immediatey, ...). Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] diverting HandlePowerKey
On Thu, 16.08.12 13:16, Robin Becker (ro...@reportlab.com) wrote: On 16/08/2012 12:47, Mantas Mikulėnas wrote: On Thu, Aug 16, 2012 at 2:23 PM, Robin Becker ro...@reportlab.com wrote: It'd be a bit better if the button/lid events were handled by a program running inside the Openbox session (the events can be read from /run/acpid.socket). I'm not exactly sure here, but aren't the standard power events in systemd handled by a daemon running outside openbox? I thought that the handler kinds eg no-session, tty-session, any-session were supposed to allow some control over whether I can switch off the machine with other users logged on etc etc. Perhaps with cgroups those sorts of capabilities can be passed on to another program. Openbox is actually running as a user process so it has no greater rights than the user; that makes the use of a more capable daemon a bit more reasonable. Normally, logind only handles the power buttons if no X session is in the foreground. If it is we assume that the DE on it handles the power/sleep/lid events like any other key and does the right thing. The ability to set things to any-session exists only for compatibility if people run DEs that don't handle this internally, but it is not interactive. If you want interactivity, then make your DE handle this key. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] diverting HandlePowerKey
On Thu, 16.08.12 16:27, Robin Becker (ro...@reportlab.com) wrote: However, I'm a bit lost on what's the correct way for a user program to signal that it wants to shut down etc. Slim appears to be running polkit/consolekit so presumably I can use that, but is there a preferred systemd approach? Clearly just doing sudo halt etc etc is the wrong approach. Invoke the PowerOff() call on the org.freedesktop.login1.Manager interface of the /org/freedesktop/login1 object on the org.freedesktop.login1 service. Which is basically what systemctl poweroff does. Is there a way to divert HandlePowerKey to a script of my choosing? No, there currently isn't. Eventually might add something that would allow people to reconfigure what happens when people press the power/sleep keys. But I am not sure we'll allow specification of arbitrary scripts for that. sounds a bit strict, but perhaps I'm a bit of an anarchist. I definitely think you should allow control over whether suspend or hibernate or shutdown gets done for at least the lid button. Well, we try to cover the big usecases for this and do not intend to provide a solution for everything thinkable. I mean, we make sure that other components of the OS can get these keypresses too, so that people have full flexibility in what they want to happen if the stuff in systemd itself does not cover their specific usecase fully. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
