Re: s6-linux-init: SIGUSR1 and SIGUSR2

From: Guillermo <gdiazhartusch_at_gmail.com>
Date: Sun, 21 Aug 2016 18:17:10 -0300

2016-08-21 6:15 GMT-03:00 Laurent Bercot:
>
> On 21/08/2016 06:18, Casper Ti. Vector wrote:
>>
>> It seems that the exchanging of SIGUSR1 and SIGUSR2 [1] in s6-linux-init
>> did not happen. Is it just forgotten, or ...?
>
> Well, by the point I remembered to make the change, I already had
> systems depending on the old behaviour :/

Heh. At the time this was brought up on the skaware ML, s6-rc had been
released a month before, s6-svscan had recently gained the signal
diversion feature (-s option), and s6-linux-init-maker (from
s6-linux-init), the ability to generate diverted signal handlers and
plug in a stage2_finish script, so that s6-rc could be added to the
init system. But what no skarnet.org packages provided at the time was
programs that sent signals to process 1. With the SIGUSR1/2 swap,
BusyBox's halt, poweroff and reboot applets would have been able do
the job. But s6-halt, s6-poweroff and s6-reboot (from s6-linux-utils
version >= 2.1.0.0) can now send signals to process 1, so the issue
was resolved, although in a different way.

> It's purely a convention anyway, and busybox init, sinit and sysvinit all
> disagree - so I'm afraid there can't be a generic "shutdown" client;
> every init system must come with its own "shutdown" program, that honors
> its own convention.

Yeah, it seems it has come to that :) But the funny thing is a few of
the init systems for [GNU/]Linux are, or can be made to be, *almost*
(to different degrees) compatible with this signal set:

a) SIGTERM for reboot
b) SIGUSR1 for halt
c) SIGUSR2 for poweroff
d) SIGINT for a programmable CTRL + ALT + Del action
e) SIGWINCH for a programmable 'keyboard request' action

sysvinit a.k.a van Smoorenburg init supports d) and e) via lines with
the 'kbrequest' and 'ctrlaltdel' actions in /etc/inittab, but not a)
to c). That is handled instead by communication over the /dev/initctl
FIFO.

BusyBox init supports almost all, even d) via lines with the
'ctrlaltdel' action in /etc/inittab (if it was built with
FEATURE_USE_INITTAB enabled), but not e).

nosh's system-manager supports e) via the 'kbrequest' target. But for
compatibility reasons, supports d) on [GNU/]Linux via the
'secure-attention-key' target, but not on the BSDs, where SIGINT means
'halt'. Supports a) and b) on the BSDs, but not c), because SIGTERM
means 'enter rescue mode'. And doesn't support a) to c) on
[GNU/]Linux, because it follows the systemd signal convention (signals
above SIGRTMIN) there instead.

It should be noted that one can make s6 + s6-rc support a) to d) with
little effort by running s6-linux-init-maker, and then adapting the
diverted signal handlers instead of using them as-is:

* swapping $basedir/run-image/.s6-svscan/SIGUSR1 and
$basedir/run-image/.s6-svscanSIGUSR2
* moving $basedir/run-image/.s6-svscan/SIGINT to
$basedir/run-image/.s6-svscan/SIGTERM
* and writing a custom $basedir/run-image/.s6-svscan/SIGINT. E.g. one
that chains to, say, /etc/s6-init/ctrlaltdel if that file exists and
is executable, and returns 0 if not.

What can't be implemented is e), because s6-svscan can't currently
divert SIGWINCH. And even then, one would also need a (Linux-specific)
chainloading tool that does the KDSIGACCEPT ioctl for SIGWINCH on
/dev/console to enable the feature, so it could be insterted in the
stage1 script before it redirects stdin and chains to s6-svscan. But
that tool can be written without much effort either, I think.

G.
Received on Sun Aug 21 2016 - 21:17:10 UTC