Re: New reboot flag: -c for 'power cycle'
2017-10-29 22:24 GMT-03:00 Guillermo: > > [...] or to call a program that does this reboot(RB_POWERCYCLE) thing > on FreeBSD, if it's implemented. Scratch this part; it would have to be called by the stage3 init, not the SIGWINCH handler. But it was an example, the rest of the message still stands. G.
Re: New reboot flag: -c for 'power cycle'
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 . G.
Re: New reboot flag: -c for 'power cycle'
Which reminds me, are there any plans to add SIGWINCH to the set of signals that 's6-svscan -s' can divert? 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. -- Laurent
Re: New reboot flag: -c for 'power cycle'
(Quoting this e-mail for context) 2017-10-29 5:37 GMT-03:00 Jonathan de Boyne Pollard: > > Since SIGWINCH to process #1 is already taken by Linux, I have adjusted my > softwares to use SIGRTMIN+7 and SIGRTMIN+17 for the signals to process #1 > for this, ready for when Linux eventually catches up with this idea. (-: Which reminds me, are there any plans to add SIGWINCH to the set of signals that 's6-svscan -s' can divert? G.
Re: New reboot flag: -c for 'power cycle'
Warner Losh, FreeBSD and embedded systems developer, has just invented a new shutdowngoal, in addition to the ones that we already know. In addition to the conventional reset, power off, halt, and kexec goals; xe has added a power-off-and-then-on-again goal. Xe has named it power cycle, and its use case is systems with hardware that can trigger a full power cycle under the kernel's controland where an ACPI reset or even an EFI ResetSystem() of type EfiResetColdjust do not cutthe mustard. It involvesanew flag to the FreeBSD reboot() system call, RB_POWERCYCLE; new FreeBSD kernel functionality for enacting this with hardwares that support it; new -c (for "cycle") flags to the various reboot, halt, poweroff, and shutdown commands; and a new signal sent to process #1. * https://marc.info/?l=freebsd-arch&m=150886821625848&w=2 * https://reviews.freebsd.org/D12777 This of course impacts those of us who write process #1 programs. Since SIGWINCH to process #1 is already taken by Linux, I have adjusted my softwares to use SIGRTMIN+7 and SIGRTMIN+17 for the signals to process #1 for this, ready for when Linux eventually catches up with this idea. (-: (There is an on-going discussion of whether FreeBSD's old init program should use real-time signals, too. It currently does not.But that is a side issue here. I have also added to my softwares powercycle and fastpowercycle commands and subcommands, a "c" or "C" argument to the compatibility telinit program (by analogy to the existing letters, although I might have to pick another letter), a powercycle target (again by analogy to existing targets), and a --powercycle long option equivalent for -c .) Please do not use SIGRTMIN+7 and SIGRTMIN+17 for an incompatible purpose.
Re: New reboot flag: -c for 'power cycle'
Warner Losh: I was completely unaware of SIGWINCH being used like this on Linux. It didn't pop up in the quick research I did before implementing this. But it would have been nice to know this sooner, but I'm OK with later since it isn't much later. Some sources of information for you, and for anyone else interested: * The "System event response" section of my system-manager(1). (http://jdebp.eu./Softwares/nosh/guide/system-manager.html or file:///usr/local/share/doc/nosh/system-manager.html if you have the nosh Guide installed) * The SIGNALS section of Miquel van Smoorenburg's init(8). (http://svn.savannah.gnu.org/viewvc/sysvinit/sysvinit/trunk/man/init.8) * The SIGNALS section of Gerrit Pape's runit(8). (http://smarden.org/runit/runit.8.html) * The SIGNALS section of systemd(8). (https://www.freedesktop.org/software/systemd/man/systemd.html) * The doco for signal handling in Joachim Nilsson's finit. (https://github.com/troglobit/finit/blob/master/doc/signals.md) * Felix von Leitner (2004-09). Speeding up the Linux boot process with minit. https://www.fefe.de/minit/minit-linux-kongress2004.pdf. 11th Linux Kongress. p. 14. * https://unix.stackexchange.com/a/191875/5132 * https://unix.stackexchange.com/a/197472/5132 * https://www.mail-archive.com/supervision@list.skarnet.org/msg01344.html
