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.