為什麼我們不能殺死不間斷的 D 狀態程序？
由於防火牆後面的 NFS 共享，我經常遇到程序卡在 D 狀態的問題。如果我失去連接，程序會卡在 D 狀態，我無法殺死它們。唯一的解決方案是硬重啟。我想知道是否還有其他方法，但我能找到的所有解決方案和資訊都是“你無法殺死它”。每個人似乎都可以接受並接受它的方式。我對此有點批評。我認為必須有一種方法可以從記憶體中刮掉程序，這樣就不需要重新啟動。如果這種情況經常發生，那就太煩人了。如果資源恰好返回 IO，在這種情況下可以簡單地忽略它。為什麼這不可能？Linux核心恕我直言非常先進，您應該能夠做這樣的事情。特別是在伺服器…
我找不到令人滿意的答案，為什麼不/不能實現？
我也對有關程式和算法性質的答案感興趣，這將解釋這個問題。
在系統呼叫中殺死一個程序是可能的，而且它大部分都有效。困難的是讓它一直工作。從 99.99% 到 100% 是困難的部分。
通常，當一個程序被殺死時，它使用的所有資源都會被釋放。如果程序正在進行任何 I/O，則會通知執行此 I/O 的程式碼並退出，從而釋放它正在使用的資源。
當“程式碼被通知並退出”時，不間斷的睡眠明顯發生，花費了不可忽略的時間。這意味著程式碼不能正常工作。這是一個錯誤。是的，理論上可以編寫沒有錯誤的程式碼，但實際上是不可能的。
您說“如果資源恰好返回 IO，則可以簡單地忽略它”。好吧，好吧。但是假設例如外圍設備已被程式為寫入屬於該程序的記憶體。要在不取消對外圍設備的請求的情況下終止程序，記憶體必須以某種方式保持在使用中。您不能只是擺脫該資源。有些資源必須留在身邊。並且只有在核心知道哪些資源可以安全釋放時才能釋放其他資源，這需要以始終可以分辨的方式編寫程式碼。不間斷睡眠持續可見時間的情況是無法判斷的情況，唯一安全的事情就是走。
可以設計一個作業系統，保證殺死一個程序可以工作（在某些關於硬體正常工作的假設下）。例如，硬實時作業系統保證殺死一個程序至多需要一定的固定時間（假設它提供了一個殺死工具）。但這很困難，特別是如果作業系統還必須支持廣泛的外圍設備並提供良好的常見情況性能。Linux 在許多方面都偏愛常見情況行為而不是最壞情況行為。
覆蓋所有程式碼路徑非常困難，尤其是從第一天起就沒有嚴格的框架來執行此操作時。在宏偉的計劃中，無法殺死的程序極為罕見（當它們沒有發生時，您不會注意到）。這是錯誤驅動程序的症狀。在編寫 Linux 驅動程序方面付出了有限的努力。要消除更多長時間不間斷睡眠的情況，要麼需要更多的人來完成任務，要麼會導致硬體支持減少和性能下降。