如何在Linux上停止“不可中断”的进程?

57

我有一个VirtualBox的进程一直挂着,我试图结束它(KILL/ABORT),但是没有成功。该进程的父进程id是1(init)。

top显示该进程为D状态,文档中描述为“不可中断的休眠”状态。

strace没有显示任何信息。

我该如何处理这个问题?这阻止了我卸载VirtualBox内核驱动程序以加载更新版本。


就我所见,这个还没有上线。不管怎样,谢谢你的建议。 - Tilo Prütz
6个回答

51

简单回答:你不能。

更长的回答:不间断睡眠意味着进程将不会被信号唤醒。它只能被等待的事物唤醒。当我遇到这种情况,例如光盘驱动器时,通常会使用挂起到磁盘并恢复来重置计算机。


11
好的,我有一个不间断的睡眠进程,我该如何找出它在等待什么?是哪个进程,真正阻塞了磁盘IO? - Max
1
例如,在文件管理器(doublecmd)中,当它等待无响应的sshfs挂载时,唯一的解决方案是完全杀死sshfs,这将释放文件管理器进程从D状态。 - Ilia
1
这些进程为什么不能立即被中断的技术原因是什么?如果内核被打补丁以强制立即终止这些进程,会怎样?情况是即使内核也无法停止它,例如CPU核心已禁用中断吗?(尽管如果有一种方法可以触发NMI,例如通过APIC,甚至也可以解决这个问题。) - flarn2006

30
Killing一个不间断的进程是可以成功的,只是不会立即执行。该进程直到接收到信号后才会消失。因此,仅发送信号是不足以摆脱该进程的,您还必须将其从不间断睡眠中唤醒。
Tanel Poder撰写了一篇关于分析D状态进程的指南。这种状态通常是由于I/O不完整,例如网络故障引起的。slm在superuser上发布了一些非常有用的提示,介绍了如何解决网络I/O问题以及该问题本身。

个人而言,在使用VirtualBox上的Windows,甚至是Wine时,我经常遇到由于CDROM I/O未能完成(我猜测这是某种光盘存在检查)而导致的问题。ATA设备可以被重置,这可能会解除进程阻塞。例如,我正在使用以下小脚本来重置我的两个光驱,解除它们所阻塞的进程:

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

1
不得不使用/sys/block/srX/device/delete而不是仅仅使用/sys/block/srX/delete,但这个方法很有效! - genpfault

20

D状态基本上意味着进程正在等待磁盘I/O或其他无法中断的块I/O。有时这意味着内核或设备正在疯狂地尝试读取坏块(特别是来自光盘)。有时它意味着还有其他问题。

在进程退出D状态之前,无法将其终止。找出它正在等待什么并解决该问题。简单的方法是重新启动。有时删除相关的磁盘可以帮助解决问题,但这可能相当危险:如果不知道自己在做什么(即:冒烟),则会导致无法修复的灾难性硬件故障。


我遇到了这个问题,因为我在单线程模式下使用fusepy,并从FUSE回调函数本身内部访问了挂载点。现在它正在等待自己,我无法杀死进程本身或任何试图从该挂载点读取的内容...难道我真的需要重启吗? - mxmlnkn
我的意思是,这不是一个安全漏洞吗?我可以用这个方法砖化任何系统。只需创建一个FUSE挂载点并将其置于不可中断的睡眠状态,然后在后台启动“ls <mountpoint>”,直到达到进程限制为止。哇,就这样,无法启动新进程了。我实际上已经遇到过进程限制,因为我不小心做了类似这样的事情:“while true; do sleep 1h & done”。 - mxmlnkn
好的,我可以使用 sudo umount -f <挂载点> 关闭所有内容而无需重新启动。此外,还有一个FUSE控制系统),这也可能有效。 - mxmlnkn

5
我最近在远程服务器上遇到了一个处于 D 状态的进程,并且想要澄清,需要进行 硬重启 或者断电操作来移除该进程。
在尝试软重启之前,请确保您已经尝试了所有其他选项。例如,您可以尝试释放该进程挂起的任何资源。软重启可能会导致系统部分关闭并且不再响应 ssh,但是由于被阻塞的无法中断进程而无法重启。

4
正如其他人所说,一个不可中断的进程是一个被卡在内核函数中且无法中断的进程(通常是等待某些I/O操作)。有关详细描述,请参见此答案
除了重新启动计算机外,我成功地通过清除Linux VM缓存来将某些进程从D状态中恢复。
kill -9 {process_id}
sync
echo 3 | sudo tee /proc/sys/vm/drop_caches

这似乎不会影响系统稳定性,但我不是系统程序员,也不确定可能会产生什么意外后果。


编辑:

根据内核文档drop_caches在开发环境中似乎相对安全。

drop_caches

Writing to this will cause the kernel to drop clean caches, as well as reclaimable slab objects like dentries and inodes. Once dropped, their memory becomes free.

To free pagecache:

echo 1 > /proc/sys/vm/drop_caches

To free reclaimable slab objects (includes dentries and inodes):

echo 2 > /proc/sys/vm/drop_caches

To free slab objects and pagecache:

echo 3 > /proc/sys/vm/drop_caches

This is a non-destructive operation and will not free any dirty objects. To increase the number of objects freed by this operation, the user may run `sync' prior to writing to /proc/sys/vm/drop_caches. This will minimize the number of dirty objects on the system and create more candidates to be dropped.

This file is not a means to control the growth of the various kernel caches (inodes, dentries, pagecache, etc...) These objects are automatically reclaimed by the kernel when memory is needed elsewhere on the system.

Use of this file can cause performance problems. Since it discards cached objects, it may cost a significant amount of I/O and CPU to recreate the dropped objects, especially if they were under heavy use. Because of this, use outside of a testing or debugging environment is not recommended.

You may see informational messages in your kernel log when this file is used:

cat (1234): drop_caches: 3

These are informational only. They do not mean that anything is wrong with your system. To disable them, echo 4 (bit 3) into drop_caches.


-3

我在这里是新手,经验不丰富。但我遇到了相同的问题,当我使用htop检查进程状态时,我可以看到它们进入了不可中断的睡眠状态(D状态)。

由于某种原因,

kill -9 <pid>

对我有用。也许你可以尝试一下。

编辑:详细的答案已经由ostrokach提供(我没有看到)。


5
你刚刚运气好。 - foo

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接