我正在面临一个关于发送信号9（SIGKILL）到init进程（PID 1）的奇怪问题。 正如您所知，SIGKILL不能通过信号处理程序忽略。 当我试图发送SIGKILL到init时，我注意到没有任何事情发生。 init不会被终止。 为了弄清楚这种行为，我决定用strace把自己附加到init进程中，以便更清楚地看到发生的事情。 现在来了怪异的一部分。 如果我用strace“发现”init进程并发送SIGKILL，系统就会崩溃。
我的问题是为什么会发生这种情况？ 为什么当我看着这个过程时系统崩溃了，为什么当我不在的时候崩溃呢？ 正如我所说的，在这两种情况下，我发送SIGKILL到init。 testingCentOS 6.5，Debian 7和Arch。
谢谢！
如果init终止，Linux内核会故意强制系统崩溃（请参阅http://lxr.free-electrons.com/source/kernel/exit.c?v=3.12#L501 ，特别是其中的panic调用）。 因此，作为一个安全措施，内核不会向init发送任何致命的信号， SIGKILL也不例外（参见http://lxr.free-electrons.com/ident？v = SIGKILL = SIGIGNAL_UNKILLABLE ）（但是，代码流程是错综复杂的，我不知道，但我怀疑内核生成的SIGSEGV或类似的会通过）。
应用ptrace(2) （ strace使用的系统调用）处理1显然禁用了这种保护。 这可以说是内核中的一个bug。 我没有足够的技巧来挖掘代码来发现这个bug。
我不知道其他Unix变体是否将相同的出口崩溃语义或信号保护应用于init 。 如果init终止（至少，如果通过调用_exit ），操作系统将执行干净的关闭或重新启动，而不是一个恐慌是合理的，但据我所知，所有现代的Unix变种都有一个专用的系统调用来请求这个，而不是（ reboot(2) ）。