所以，这件事多年来一直困扰着我。
这种情况发生在更多的程序中，而不仅仅是 dd ，但我发现这种情况经常发生在涉及原始文件系统操作的程序中。
当我使用 dd 进行复制时——例如，通过执行 来制作可启动 USB 磁盘sudo dd if=somelinuxdistro.iso of=/dev/sdb bs=64K status=progress，就像我的所有信号都被应用程序忽略了。 （或者在 的情况下由内核SIGKILL）htop显示 status D，这显然意味着“不间断睡眠”。它可以保持这种状态年龄如果出现硬件故障，并且在常规使用中，我似乎找不到任何方法将其与终端分离，以便我可以继续工作 - 通常我最终只是切换到不同的终端来完成我的工作。
我以前查过这个，但我从未找到关于此状态的用途或内核为何拒绝终止处于此状态的进程的解释，或者建议做什么以避免浪费时间。 （也没有任何建议做当这个情况发生时。）
简而言之： 我想要一种可靠地强制终止处于 D 状态的进程的方法，或者至少将它们与终端分离。我还想解释一下背景中发生的事情导致他们首先处于这种状态。
答案1
如果您无法中断“不间断读取”，并且这与关闭的 NFS 服务器无关，则您发现了驱动程序错误。
本地后台存储的 I/O 超时不应超过 5-10 分钟。因此，如果您键入^Cor^Z并在 10 分钟内没有任何反应，则存在驱动程序错误。
背景是UNIX定义了所谓的fast IO不可被信号中断，因为快速IO将在可预见的时间后终止。
使 IO 可通过信号中断会导致较高的开销，因为需要返回到干净状态。 IO 启动后发生的所有事情都需要展开，并且返回只能从 IO 启动的位置发生。
更糟糕的是，如果后台存储驱动程序确实实现了可中断 IO，这将导致此类驱动程序之上的文件系统出现无法处理的问题。您正在使用旨在用作文件系统后台存储的驱动程序......
您可以致电dmesg并检查内核消息以解决您的问题。如果中断在 10 分钟后确实不起作用（当一个读或写系统调用预计会超时并且有可能dd在两个此类系统调用之间终止）时，您需要重新启动。
如果这是 USB 设备，您可以尝试在重新启动之前拉出该设备。