On 26/04/2015 15:03, bougyman wrote:
Running runit-init on void linux (it's our default), a user recently brought to our attention that using the sysrq-k (SAK) magic key causes a panic because PID 1 is killed. We are assuming this is because runit-init holds on to descriptors to /dev/console. Is there a known way to work around this? Does s6-init suffer from the same?
You could patch runit so that it redirects fd 0 to /dev/null instead of /dev/console. Unless init is a shell or some other interactive program, there is no good reason to use /dev/console as stdin - it's never read, it only gets in the way, and gettys will open their own terminal themselves. It is useful to keep /dev/console for stdout and stderr, though; this shouldn't hurt (and if having write-only fds on /dev/console makes a process eligible for SAK kills, then I wonder how sysvinit does it). s6-init is not out yet, but the official example on how to run s6-svscan as process 1 includes redirecting stdin to /dev/null in the stage 1 script, and stdout/stderr to something else than /dev/console as well. So if you follow those steps, s6-svscan should definitely be immune to SAK. Note that if SAK actually kills init if it is listening on /dev/console, it is a flaw in Linux that warrants reporting to LKML. There is not a single reason why the kernel should kill init, not as long as it panics on init death instead of doing something sensible like rebooting. The kernel should check for PID 1 on any sysrq that sends a SIGKILL. -- Laurent
