为什么我可以在 debian 中杀死状态 D 的进程？

Question

他们说我们不能杀死状态 D 的进程，但我只是这样做了，为什么？

 ps aux | grep ./a
aa       21431  0.0  0.0   4224  1044 pts/0    S    23:14   0:00 ./a
aa       21818  0.0  0.0   4224  1000 pts/0    S    23:15   0:00 ./a
aa       22160  0.0  0.0   4224   744 pts/0    D    23:15   0:00 ./a
aa       22161  0.0  0.0   4224   744 pts/0    S    23:15   0:00 ./a
aa       22195  0.0  0.0  14224   928 pts/1    S+   23:15   0:00 grep --color=auto ./a
 kill -9 22160
ps aux | grep ./a
www-data 18214  0.0  0.5 830604 10752 ?        Sl   06:25   0:09 /usr/sbin/apache2 -k start
aa       21818  0.0  0.0   4224  1000 pts/0    S    23:15   0:00 ./a
aa       22161  0.0  0.0   4224  1008 pts/0    S    23:15   0:00 ./a
aa       22430  0.0  0.0  14224  1016 pts/1    S+   23:16   0:00 grep --color=auto ./a

Answer 1

Unix 的一些（但不是全部）实现允许处于 D 状态的进程被 SIGKILL 终止。

D 状态睡眠也可能在您键入“kill”命令时结束。 D 状态不应该持续很长时间。

无论如何，您不能依赖一个处于 D 状态的进程可以通过任何方式杀死，除非重新启动整个计算机。这就是为什么“他们”说他们说的话。

Answer 2

你不能杀死一个卡在不可中断 D 状态的进程。有两种可能性。您的进程很容易不会被卡住，它可能只是将大部分时间花在不可中断的 D 状态。

另一种可能性是您的进程卡在可杀死状态。为了向后兼容，我希望这显示为 D 状态。

至少man ps 没有为可杀状态列出不同的字母。 man proc (/proc/[pid]/stat) 也没有。

TASK_KILLABLE - LWN.net, 2008

Unix 传统（因此几乎所有应用程序）认为文件存储写入是不可信号中断的。更改该保证既不安全也不实际。

因此，我们似乎永远被偶尔的阻塞和不朽的过程所困。

也许不是。不久前，Matthew Wilcox 意识到，如果应用程序无论如何都将被终止，那么许多关于应用程序错误的担忧并不真正适用。如果系统调用注定永远不会返回用户空间，开发人员是否考虑过系统调用中断的可能性并不重要。于是 Matthew 创建了一个新的睡眠状态，称为 TASK_KILLABLE；它的行为类似于 TASK_UNINTERRUPTIBLE，但致命信号会中断睡眠。

[...]

内核中（从 2.6.26-rc8 开始）实际使用这种新状态的位置数量非常少 - 例如，在计算手指时不必担心手指用完。 NFS 客户端代码已经转换，这只能是一个受欢迎的开发。但是 TASK_KILLABLE 的其他用途很少，而且在设备驱动程序中根本没有，这通常是进程被楔入的地方。

新的 API 在内核中广泛使用可能需要一段时间，尤其是当它补充了大多数情况下运行良好的现有功能时。

我碰巧注意到 TASK_KILLABLE 现在也被 balance_dirty_pages() 使用，至少 in Linux v4.19。这是处理块内部的内核函数，当它们填满内核写回缓存时。所以我 认为 非同步文件系统 write() 调用现在是可终止的。 （也许同步的也是如此，我没有检查）。