关于将信号9(SIGKILL)发送到init进程(PID 1),我面临一个奇怪的问题.
您可能知道,SIGKILL不能通过信号处理程序忽略.当我尝试将SIGKILL发送给init时,我发现没有发生任何事情; init不会被终止.试图找出这种行为,我决定将自己附加到带有strace的init进程,也可以更清楚地看到发生了什么.现在是奇怪的部分.如果我用strace“查看”init进程并将其发送给SIGKILL,系统崩溃了.
您可能知道,SIGKILL不能通过信号处理程序忽略.当我尝试将SIGKILL发送给init时,我发现没有发生任何事情; init不会被终止.试图找出这种行为,我决定将自己附加到带有strace的init进程,也可以更清楚地看到发生了什么.现在是奇怪的部分.如果我用strace“查看”init进程并将其发送给SIGKILL,系统崩溃了.
我的问题是为什么会发生这种情况？为什么当我查看进程时系统崩溃,为什么在我没有崩溃时它不会崩溃？正如我所说,在这两种情况下我都将SIGKILL发送给init.在CentOS 6.5,Debian 7和Arch上测试过.
谢谢！
如果init终止,Linux内核故意强制系统崩溃(参见
http://lxr.free-electrons.com/source/kernel/exit.c?v=3.12#L501,尤其是对其中的恐慌调用).因此,作为一种安全措施,内核不会向init发送任何致命信号,并且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)).
