为什么我们不能杀死不可中断的D状态进程？

Question

由于防火墙后面的 NFS 共享，我经常遇到进程陷入 D 状态的问题。如果我失去连接，进程就会陷入 D 状态，我无法杀死它们。唯一的解决办法是硬重启。我想知道是否还有其他方法，但我能找到的所有解决方案和信息都是“你无法杀死它”。每个人似乎都很好并接受它的方式。我对此有些批判。我认为必须有一种方法可以从内存中刮掉进程，这样就不需要重新启动了。如果这种情况经常发生，那就很烦人了。如果资源碰巧返回 IO，在这种情况下可以简单地忽略它。为什么这不可能？恕我直言，Linux 内核非常先进，你应该能够做这样的事情。尤其是在服务器...

我找不到满意的答案，为什么不/不能实现？

我也会对有关编程和算法性质的答案感兴趣，这可以解释这个问题。

Answer 1

在系统调用中杀死一个进程是可能的，而且它主要是有效的。困难的是让它一直工作。从 99.99% 到 100% 是困难的部分。

通常，当一个进程被杀死时，它使用的所有资源都会被释放。如果进程有任何 I/O，执行此 I/O 的代码会被通知并退出，从而允许释放它正在使用的资源。

当“代码被通知并退出”花费了不可忽略的时间时，不间断的睡眠就会明显地发生。这意味着代码无法正常工作。这是一个错误。是的，理论上可以编写没有错误的代码，但实际上是不可能的。

你说“如果资源碰巧返回了 IO，它可以简单地被忽略”。好吧，好吧。但是假设例如一个外围设备已被编程为写入属于该进程的内存。为了在不取消对外围设备的请求的情况下终止进程，内存必须以某种方式保持使用状态。你不能只是摆脱那个资源。有些资源必须留在身边。并且只有在内核知道哪些资源可以安全释放时才能释放其他资源，这需要以始终可以分辨的方式编写代码。不间断睡眠持续可见时间的情况是无法判断的情况，唯一安全的方法是方法。

可以设计一个操作系统，在该操作系统中可以保证杀死进程（在硬件正常工作的某些假设下）。例如，硬实时操作系统保证杀死进程最多需要一定的固定时间（假设它完全提供杀死设施）。但这很困难，特别是如果操作系统还必须支持广泛的外围设备并提供良好的通用情况性能。Linux 在很多方面都偏爱普通情况下的行为而不是最坏情况下的行为。

获取所有代码路径是极其困难的，尤其是当从第一天开始就没有严格的框架来执行此操作时。在总体方案中，不可杀死的进程极为罕见（当它们没有发生时，您不会注意到）。这是错误驱动程序的症状。在编写 Linux 驱动程序方面付出了有限的努力。要消除更多长时间不间断睡眠的情况，要么需要更多的人来完成任务，要么导致支持的硬件更少，性能更差。