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.
Thanks!
The Linux kernel deliberately forces a system crash if
init
terminates (see http://lxr.free-electrons.com/source/kernel/exit.c?v=3.12#L501 and particularly the call topanic
therein). Therefore, as a safeguard, the kernel will not deliver any fatal signal toinit
, andSIGKILL
is not excepted (see http://lxr.free-electrons.com/ident?v=3.12&i=SIGNAL_UNKILLABLE) (however, the code flow is convoluted enough that I'm not sure, but I suspect a kernel-generatedSIGSEGV
or similar would go through).Applying
ptrace(2)
(the system call thatstrace
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, ifinit
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)
).