2017-10-29 18:01 GMT-03:00 Laurent Bercot:
>
>  Maybe, if it's needed. SIGWINCH is not POSIX, and I'd rather not have
> s6 exhibit different behaviours on systems where it's not supported
> (same reason why I'm reluctant to add pid namespace support to
> s6-supervise). If there's a way to make it entirely transparent, why not.

It looks like there might be. It could be handled just like SIGUSR1
and SIGUSR2 currently are: no-operation for 's6-svscan -S', execute a
diverted signal handler for 's6-svscan -s'. The system-specific policy
is encoded in the handlers (in this case, in a hypothetical
.s6-svscan/SIGWINCH handler if the corresponding mechanism existed),
which aren't provided by s6.

s6-linux-init-maker on the other hand can continue to not generate a
SIGWINCH handler, since there is no sensible default, but IIUC for
's6-svscan -s' a diverted signal with no handler is also a
no-operation, so no observable behaviour change here. However, an
administrator or distribution can provide a handler, e.g. to match
whatever its sysvinit or systemd SIGWINCH policy is, as encoded in
their shipped /etc/inittab or /usr/lib/systemd/system/kbrequest.target
files, or to call a program that does this reboot(RB_POWERCYCLE) thing
on FreeBSD, if it's implemented.

And skalibs' sig_name() already knows about SIGWINCH on OSes that
define it in <signal.h>.

G.

Reply via email to