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
Received on Sun Apr 26 2015 - 22:08:17 UTC