Re: s6-linux-init: SIGUSR1 and SIGUSR2

From: Guillermo <gdiazhartusch_at_gmail.com>
Date: Mon, 22 Aug 2016 23:31:09 -0300

2016-08-22 7:15 GMT-03:00 Laurent Bercot:
>
> The next s6+friends version release will have major version bumps all
> around, so compatibility is moot anyway. If you really think it's worth it
> to swap SIGUSR1 and SIGUSR2, I'll do it.

It would be more aesthetically pleasing if s6-halt sent SIGUSR1,
s6-poweroff sent SIGUSR2, and s6-reboot sent SIGTERM, in the sense
that it would make a couple of init systems almost agree, but that's
it. At this point, reassigning the 'reboot' meaning to SIGTERM would
probably more useful than swapping SIGUSR1 and SIGUSR2, because it
frees SIGINT, an therefore CTRL + Alt + Del, to do whatever the
administrator or distribution pleases, like in the
/etc/s6-init/ctrlaltdel example I gave.

But from a user's point of view, as long as s6-halt, s6-poweroff and
s6-reboot "just work" and do what they say they do, everything is OK.
Which means that 'out of the box' s6-linux-utils programs have to
agree with 'out of the box' s6-linux-init handlers, and this happens
already. Also, the way s6-svscan implements signal diversion is
flexible, so one can rearrange or modify s6-linux-init's handlers to
align with a different convention than s6-linux-utils' current one.

So, in conclusion: alignment with BusyBox init's convention is nicer,
but if you feel you'd rather use the time for something else, or if
changing the convention would break too many things, then I'd say
don't bother.

> I can also add SIGWINCH support to s6-svscan, but only when it's diverted,
> because there's no possible portable default semantics.

This would be nice to have, with the same treatment SIGUSR1 and
SIGUSR2 currently have: completely ignore them with -S, divert them
with -s. Last time I checked with a 3.14-series kernel, loadkeys(1)
and a suitable keymap file, the 'keyboard request' still worked (it is
usually mapped to Alt + Up arrow). And besides the init systems I
mentioned, systemd supports it too. So yeah.

The only additional requirement to use it is a Linux-specific
'ioctl(fd, KDSIGACCEPT, SIGWINCH)' call to turn 'keyboard request' on,
because last time I experimented, I found it to be off by default when
the kernel starts. s6-svscan can't do the ioctl itself without losing
portability, but a separate chainloading program in stage1 can.

Thanks,
G.
Received on Tue Aug 23 2016 - 02:31:09 UTC