I'm facing a weird issue regarding sending signal 9 (SIGKILL) to the init process (PID 1). As you may know, SIGKILL can't be ignored via signal handlers. As I tried sending SIGKILL to init, I noticed that nothing was happening; init would not get terminated. Trying to figure out this behaviour, I decided to attach myself to the init process with strace too see more clearly what was happening. Now comes the weird part. If I'm "looking" at the init process with strace and send it SIGKILL, the system crashes.
My question is why is this happening? Why does the system crash when I look at the process and why does it not crash when I'm not? As I said, in both cases I send SIGKILL to init. Tested on CentOS 6.5, Debian 7 and Arch.
The Linux kernel deliberately forces a system crash if init
terminates (see https://elixir.bootlin.com/linux/v3.12/source/kernel/exit.c#L501 and particularly the call to panic
therein). Therefore, as a safeguard, the kernel will not deliver any fatal signal to init
, and SIGKILL
is not excepted (see https://elixir.bootlin.com/linux/v3.12/A/ident/SIGNAL_UNKILLABLE) (however, the code flow is convoluted enough that I'm not sure, but I suspect a kernel-generated SIGSEGV
or similar would go through).
Applying ptrace(2)
(the system call that strace
uses) to process 1 apparently disables this protection. This could be said to be a bug in the kernel. I am insufficiently skilled at digging around in the code to find this bug.
I do not know if other Unix variants apply the same crash-on-exit semantics or signal protection to init
. It would be reasonable to have the OS perform a clean shutdown or reboot, rather than a panic, if init
terminates (at least, if it does so by calling _exit
) but as far as I know, all modern Unix variants have a dedicated system call to request this, instead (reboot(2)
).