如何在Linux上停止「不間斷」進程？

Question

我有一個VirtualBox進程掛在我試圖殺死（-KILL/-ABORT），但沒有成功。父pid是1（init）。

top顯示過程爲D，記錄爲「不可中斷睡眠」。

strace什麼也沒有顯示。

我該如何擺脫這個？它阻止我卸載vbox內核驅動程序來加載更新的驅動程序。

Answer 1

簡單的回答：你不能。

更長的回答：不間斷的睡眠意味着進程不會被信號喚醒。它只能被它等待的東西喚醒。當我得到這樣的情況，例如。使用CD-ROM時，我通常通過使用掛起到磁盤並重新啓動來重置計算機。

Answer 2

D狀態基本上意味着進程正在等待磁盤I/O或其他無法中斷的塊I/O。有時這意味着內核或設備正在狂熱地嘗試讀取壞塊（特別是從光盤）。有時它意味着還有別的東西。

該進程無法被殺死，直到它退出D狀態。找出它正在等待什麼並解決它。簡單的方法是重新啓動。有時候刪除有問題的磁盤會有所幫助，但這可能會非常危險：如果您不知道自己在做什麼（請參閱：煙霧出來），則會導致無法修復的災難性硬件故障。

Answer 3

我最近在遠程服務器上遇到D狀態的一個進程，並想澄清一下硬重啓或電源週期是需要刪除的過程。

直到用盡所有其他選項後才嘗試進行軟重啓。例如，您可以嘗試釋放流程掛載的任何資源。軟重啓可能會給你一個部分關閉的系統，不再響應ssh，但不會重啓，因爲它試圖終止不可中斷的進程。

Answer 4

殺死一個不可中斷的進程會成功，但它不會立即執行。該過程在實際接收信號之前不會消失。因此單獨發送信號不足以擺脫這個過程，您還必須將其從不可中斷的睡眠中喚醒。

Tanel Poder寫了很棒的guide to analyse D state processes。非常典型的是，這種狀態是由不完整的I/O引起的，例如，網絡故障。 slm已經發布了一些very useful pointers on superuser如何禁止網絡I/O，以及關於問題本身。個人而言，在VirtualBox上處理Windows時，甚至在使用wine時，我經常遇到這個問題，因爲從未完成的cdrom I/O（我猜測它是某種磁盤存在檢查）。 ATA devices can be reset，這可能會阻止這個過程。舉例來說，我使用的是下面的小腳本來重置我的兩個光驅，排障他們堵的過程：

echo 1 > /sys/block/sr0/delete 
echo 1 > /sys/block/sr1/delete 
echo "- - -" > /sys/class/scsi_host/host7/scan 

Answer 5

正如其他人所說的，不間斷的過程是卡在一個內核函數的過程不能被打斷（通常它正在等待一些I/O操作）。有關詳細說明，請參閱this answer。

除了重新啓動計算機，我有成功帶來一些流程出D狀態通過flushing linux VM caches：

kill -9 {process_id} 
sync 
echo 3 | sudo tee /proc/sys/vm/drop_caches 

這似乎並沒有影響到系統的穩定，而我不是一個系統程序員，而不是確定這可能會產生什麼意想不到的後果。

---

編輯：

按照kernel docs，drop_caches似乎是在開發環境中合理的安全。

drop_caches

寫這將導致內核刪除乾淨高速緩存，以及像目錄項和inode 可收回板的對象。一旦掉線，他們的 內存變得免費。

要釋放頁緩存：

echo 1 > /proc/sys/vm/drop_caches 

要釋放可回收板坯對象（包括目錄項和inode）：

echo 2 > /proc/sys/vm/drop_caches 

向遊離板坯對象和頁緩存：

echo 3 > /proc/sys/vm/drop_caches 

這是一個非破壞性的操作，並不會釋放任何髒物。 要增加此操作釋放的對象數量，用戶可以在寫入/ proc/sys/vm/drop_caches之前運行 `sync'。這將最大限度地減少系統上的髒對象的數量，並創建更多的候選人，以便刪除 。

此文件不是控制各種內核緩存 （i節點，目錄項，頁緩存等）的生長這些對象是自動由內核回收 當系統上的其他地方是需要的存儲器的裝置。

使用此文件可能會導致性能問題。由於它丟棄了緩存的對象，因此可能會花費大量的I/O和CPU來重新創建丟棄的對象，尤其是在它們被大量使用的情況下。因此，建議不要在測試或調試環境之外使用 。

您可能會看到參考消息在內核日誌時，這個文件是用來 ：

cat (1234): drop_caches: 3 

這些信息而已。他們並不是說你的系統有任何問題 。要禁用它們，請將4（第3位）回顯爲drop_caches。