Re: runit SIGPWR support

2020-02-24 Thread Laurent Bercot
s6-linux-init has a suitable open file descriptor. It is its standard input, before it closes it to do the slashdev test. Of course, but once the fd is closed, /dev/console should not have any impact on the process, so would a kbrequest still reach it? -- Laurent

Re: runit SIGPWR support

2020-02-24 Thread Guillermo
El lun., 24 feb. 2020 a las 19:49, Laurent Bercot escribió: > > So there is no fd to call the ioctl on, and no way for a user to trigger > a kbrequest. s6-linux-init has a suitable open file descriptor. It is its standard input, before it closes it to do the slashdev test. G.

Re: runit SIGPWR support

2020-02-24 Thread Guillermo
El lun., 24 feb. 2020 a las 19:25, Laurent Bercot escribió: > > I purposefully did not add a default SIGWINCH handler, because > sysvinit does not come with a default kbrequest in /etc/inittab. > I added a SIGPWR handler that performs a regular poweroff because > it sounds like a sane default for

Re: runit SIGPWR support

2020-02-24 Thread Laurent Bercot
However, I was not aware that kbrequest needed a special ioctl call before it can be accepted, so thank you for that; I'll add the call to s6-l-i. Scratch that. s6 never uses /dev/console as input: s6-l-i redirects stdin to /dev/null. (This is intentional, and is not changing.) So there is no

Re: runit SIGPWR support

2020-02-24 Thread Laurent Bercot
I purposefully did not add a default SIGWINCH handler, because sysvinit does not come with a default kbrequest in /etc/inittab. I added a SIGPWR handler that performs a regular poweroff because it sounds like a sane default for a power failure. I suppose I could add an empty SIGWINCH script by

Re: runit SIGPWR support

2020-02-24 Thread Guillermo
The keyboard signal can actually be set to any signal less than or equal to NSIG with the KDSIGACCEPT ioctl. sysvinit just happened to pick SIGWINCH for that, and so did systemd and nosh, presumably for compatibility. El dom., 23 feb. 2020 a las 20:53, Laurent Bercot escribió: > > Both SIGPWR an

Re: runit SIGPWR support

2020-02-24 Thread Laurent Bercot
in this case systemd compatibility can be trivially achieved, so there is no real reason to abstain from it. "systemd compatibility" makes no sense here. We are talking about runit or s6 as an init system: by definition, in that context, there is no systemd, no interaction with systemd, nothi

Re: runit SIGPWR support

2020-02-24 Thread Serge E. Hallyn
On Mon, Feb 24, 2020 at 04:12:31PM +0300, innerspacepilot wrote: > On 24.02.2020 13:23, Laurent Bercot wrote: > > > SIGRTMIN+3 should also be caught and processed. > > > >  What piece of software sends SIGRTMIN+3 to pid 1 when you're not > > running systemd? > > > > -- > >  Laurent > > > Looking

Re: runit SIGPWR support

2020-02-24 Thread innerspacepilot
On 24.02.2020 13:23, Laurent Bercot wrote: SIGRTMIN+3 should also be caught and processed.  What piece of software sends SIGRTMIN+3 to pid 1 when you're not running systemd? --  Laurent Looking at lxc sources (src/lxc/lxccontainer.c:2084) nothing will, until you block SIGRTMIN+3 signal. Eve

Re: runit SIGPWR support

2020-02-24 Thread Jeff
24.02.2020, 11:23, "Laurent Bercot" : >> SIGRTMIN+3 should also be caught and processed. why only this one and not ALL of the real time signals ? > What piece of software sends SIGRTMIN+3 to pid 1 when you're not > running systemd? in this case systemd compatibility can be trivially achieved, so

Re: runit SIGPWR support

2020-02-24 Thread Laurent Bercot
SIGRTMIN+3 should also be caught and processed. What piece of software sends SIGRTMIN+3 to pid 1 when you're not running systemd? -- Laurent