SIGKILL init过程(PID 1)

Question

我面临一个关于向init进程(PID 1)发送信号9 (SIGKILL)的奇怪问题。您可能知道，不能通过信号处理程序忽略SIGKILL。当我试图发送SIGKILL到init时，我注意到什么都没有发生，init不会被终止。为了弄清楚这种行为，我决定加入init过程，也要更清楚地看到正在发生的事情。现在出现了奇怪的部分。如果我使用strace“查看”init进程并将其发送给SIGKILL，系统就会崩溃。

我的问题是为什么会发生这种事？为什么当我查看这个过程时，系统会崩溃?为什么当我没有崩溃的时候它不会崩溃呢？正如我所说，在这两种情况下，我都会发送SIGKILL到init。测试在CentOS 6.5，Debian 7和Arch上。

谢谢!

Answer 1

如果init终止，Linux内核故意强制系统崩溃(请参阅http://lxr.free-electrons.com/source/kernel/exit.c?v=3.12#L501，特别是其中对panic的调用)。因此，作为一种保障，内核不会向init传递任何致命的信号，SIGKILL也不例外(请参阅UNKILLABLE) (但是，代码流复杂到我不确定，但我怀疑内核生成的SIGSEGV或类似的代码会通过)。

将ptrace(2) ( strace使用的系统调用)应用于进程1显然会禁用此保护。这可以说是内核中的一个bug。我没有足够的技巧在代码中挖掘找到这个bug。

我不知道其他Unix变体是否对init应用了相同的退出崩溃语义或信号保护。如果init终止(至少是通过调用_exit来终止)，让操作系统执行干净的关闭或重新启动(而不是恐慌)是合理的，但据我所知，所有现代Unix变体都有一个专门的系统调用来请求它(reboot(2))。