我正在使用Ubuntu 14.04，但遇到这种现象，我似乎无法理解：

1. 运行yes命令（在默认外壳中：Bash）
2. 键入CtrlZ停止yes
3. 运行jobs。输出：
   [1]+ Stopped yes
4. 跑kill -9 %1停yes。输出：
   [1]+ Stopped yes
5. 运行jobs。输出：
   [1]+ Stopped yes

这是在3.16.0-30-generic并行虚拟机上运行的Ubuntu 上。

为什么我的kill -9命令没有终止yes命令？我以为SIGKILL不能被抓住或忽略？以及如何终止yes命令？

信号被阻塞以暂停进程。在终端中：

$ yes
...
y
y
^Zy

[1]+  Stopped                 yes

在第二个终端中：

$ killall yes

在第一个终端中：

$ jobs
[1]+  Stopped                 yes

$ fg
yes
Terminated

但是SIGKILL不能被阻止。killall -9 yes从第二个终端执行相同的操作会立即在yes终端中给出：

[1]+  Killed                  yes

因此，如果kill -9 %1没有立即终止进程，则可能bash是直到您执行fg该进程才真正发送信号，或者您没有发现内核中的错误。

不要惊慌

没有什么时髦的事情。这里没有内核错误。这是来自Bourne Again shell和多任务操作系统的完全正常的行为。

要记住的是，一个进程会杀死自己，即使它是对它的回应SIGKILL。这里发生的是，Bourne Again shell 在它刚刚被告知要杀死自己的过程变为杀死自己之前就已经开始处理事情了。

考虑一下从yes停止位置开始发生的情况，SIGTSTP而您刚刚kill使用Bourne Again shell 执行了命令：

1. 外壳程序发送SIGKILL到yes进程。
2. 并行：
   1. 该yes进程计划运行，并立即终止自身。
   2. Bourne Again shell继续，发出另一个提示。

您看到一件事而其他人看到另一件事的原因是两个准备运行的流程之间的简单竞争，赢家完全取决于机器之间以及随时间而变化的事物。系统负载和您的CPU是虚拟的都会有所不同。

在有趣的情况下，步骤2的细节如下：

1. Bourne Again外壳继续。
2. 作为内置kill命令内部的一部分，它将作业表中的条目标记为需要在下一个可用点打印通知消息。
3. 它完成kill命令，并且在打印提示之前，再次检查以查看是否应打印有关任何作业的通知消息。
4. 该yes进程还没有杀死自己的机会，因此就外壳程序而言，该作业仍处于停止状态。因此，外壳程序为该作业打印“已停止”作业状态行，并重置其通知挂起标志。
5. 该yes过程被安排并杀死了自己。
6. 内核会通知正在忙于运行其命令行编辑器的Shell进程已终止自身。Shell会记录状态更改，并将该作业标记为再次等待通知。
7. 只需按enter一下以再次循环进行提示打印，外壳便可以打印新的作业状态。

要点是：

• 进程会自杀。 SIGKILL不是魔术。从内核模式返回到应用程序模式时，进程会检查挂起的信号，这在页面错误，（非嵌套）中断和系统调用的末尾发生。唯一的特殊之处在于，内核不允许SIGKILL立即采取无条件自杀以外的其他任何行动，并且不返回应用程序模式。重要的是，为了响应信号，进程既需要进行内核到应用程序模式的转换，又要安排运行时间。
• 虚拟CPU只是主机操作系统上的一个线程。无法保证主机已安排虚拟CPU运行。主机操作系统也不是不可思议的。
• 发生工作状态更改时，不会打印通知消息（除非您使用set -o notify）。当下一个外壳程序到达其执行周期中的某个点时，将打印它们，以检查是否有任何待处理的通知。
• 通知挂起标志被设定两次，一次通过kill，一旦由SIGCHLD信号处理程序。这意味着如果外壳程序在重新安排进程以杀死自身之前运行，则可以看到两条消息yes。一个是“已停止”消息，另一个是“已杀死”消息。
• 显然，该/bin/kill程序无权访问Shell的内部作业表。因此您不会看到的这种行为/bin/kill。通知挂起标志仅由SIGCHLD处理程序设置一次。
• 出于相同的原因，如果您从另一个外壳kill进行yes处理，则不会看到此行为。

在您的系统上可能会发生一些时髦的事情，在我的情况下，无论是否使用-9：

> yes
...
^Z
[1]+  Stopped                 yes
> jobs
[1]+  Stopped                 yes
> kill %1
[1]+  Killed                  yes
> jobs
> 

取得pid，jobs -p并尝试将其杀死root。

您正在观察的是此版本bash中的错误。

kill -9 %1会立即终止工作。您可以通过观察ps。您可以跟踪bash进程以查看何时kill调用系统调用，也可以跟踪子进程以查看何时接收和处理信号。更有趣的是，您可以查看该过程正在发生什么。

bash-4.3$ sleep 9999
^Z
[1]+  Stopped                 sleep 9999
bash-4.3$ kill -9 %1

[1]+  Stopped                 sleep 9999
bash-4.3$ jobs
[1]+  Stopped                 sleep 9999
bash-4.3$ jobs -l
[1]+  3083 Stopped                 sleep 9999
bash-4.3$ 

在另一个终端：

% ps 3083
  PID TTY      STAT   TIME COMMAND
 3083 pts/4    Z      0:00 [sleep] <defunct>

子进程是僵尸。它已经死了：它剩下的只是进程表中的一个条目（但没有内存，代码，打开的文件等）。该条目将保留下来，直到其父级注意到并通过调用wait系统调用或其同级之一来检索其退出状态。

交互式外壳程序应检查是否有死掉的孩子并在打印提示之前对其进行收获（除非另有配置）。在某些情况下，此版本的bash无法做到：

bash-4.3$ jobs -l
[1]+  3083 Stopped                 sleep 9999
bash-4.3$ true
bash-4.3$ /bin/true
[1]+  Killed                  sleep 9999

您可能希望bash在命令后打印提示后立即报告“杀死” kill，但这不能保证，因为存在竞争条件。信号是异步传递的：kill内核确定要向哪个进程传递信号后，系统调用将立即返回，而无需等待信号实际传递。在实践中，bash有可能并且确实发生了，bash有时间检查其子进程的状态，发现它仍然没有死（wait4没有报告任何孩子死亡），并打印该进程仍在停止。出问题的是，在下一个提示之前，信号已传递（ps报告该进程已死），但bash仍未调用wait4（我们可以看到，不仅因为它仍将作业报告为“已停止”，而且还因为进程表中仍然存在僵尸）。实际上，当bash wait4运行其他外部命令时，它仅在下次需要调用时才收获僵尸。

该错误是间歇性的，在跟踪bash时我无法重现该错误（大概是因为这是bash需要快速反应的竞争条件）。如果信号在bash检查之前发出，则一切都会按预期进行。