SIGKILL 初始化进程（PID 1）

Question

我遇到了一个关于将信号 9 (SIGKILL) 发送到 init 进程 (PID 1) 的奇怪问题。 如您所知，不能通过信号处理程序忽略 SIGKILL。当我尝试向 init 发送 SIGKILL 时，我注意到没有任何反应； init 不会被终止。为了弄清楚这种行为，我决定使用 strace 将自己附加到 init 进程中，以便更清楚地看到发生了什么。现在奇怪的部分来了。如果我用 strace “查看”init 进程并向其发送 SIGKILL，系统就会崩溃。

我的问题是为什么会发生这种情况？为什么当我查看进程时系统会崩溃，而当我不查看进程时系统不会崩溃？正如我所说，在这两种情况下我都会向 init 发送 SIGKILL。在 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 传递

any

致命信号，

SIGKILL

也不例外（参见 http://lxr.free-electrons.com/ident?v=3.12&i= SIGNAL_UNKILLABLE）（但是，代码流程非常复杂，我不确定，但我怀疑内核生成的

SIGSEGV

或类似的东西会通过）。

将

ptrace(2)

（

strace

使用的系统调用）应用于进程 1 显然会禁用此保护。 这可以说是内核的一个bug。 我不够熟练地挖掘代码来找到这个错误。

我不知道其他 Unix 变体是否对

init

应用相同的退出时崩溃语义或信号保护。 如果

init

终止（至少，如果它通过调用

_exit

这样做），让操作系统执行干净的关闭或重新启动，而不是恐慌，这是合理的，但据我所知，所有现代 Unix 变体有一个专用的系统调用来请求这个，而不是（

reboot(2)

）。