Linux 进程的 Uninterruptible sleep(D) 状态

最新推荐文章于 2025-03-11 11:20:08 发布

转载最新推荐文章于 2025-03-11 11:20:08 发布 · 903 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：https://blog.youkuaiyun.com/u013870094/article/details/78490911

performence 专栏收录该内容

94 篇文章

订阅专栏

本文探讨了Linux系统中无法通过常规方法终止的D状态进程问题，解析了进程为何进入此状态，以及如何通过重启系统或恢复IO来解决。并提到了特殊情况下的父进程处理策略。

运行在 KVM 虚拟机里的一些进程突然出了问题，这些出了问题的进程无法用 kill杀掉，使用 ps 可以看到这些进程处于D 状态：

   
           [build@kbuild-john ~]$ ps -a -ubuild -o pid,ppid,stat,command
          
             PID  PPID STAT COMMAND
          
           17009     1 Ds   -bash
          
           17065     1 D    ls --color=tty -al
          
           17577     1 D    /usr/java/jdk1.5.0_17/bin/java -Xmx512m -classpath /usr/local/a
          
           17629     1 D    /usr/java/jdk1.5.0_17/bin/java -Xmx512m -classpath /usr/local/a

ps 的手册里说 D 状态是 uninterruptible sleep，Linux 进程有两种睡眠状态，一种 interruptible sleep，处在这种睡眠状态的进程是可以通过给它发信号来唤醒的，比如发 HUP 信号给 nginx 的 master 进程可以让 nginx 重新加载配置文件而不需要重新启动 nginx 进程；另外一种睡眠状态是 uninterruptible sleep，处在这种状态的进程不接受外来的任何信号，这也是为什么之前我无法用 kill 杀掉这些处于 D 状态的进程，无论是 kill, kill -9 还是 kill -15，因为它们压根儿就不受这些信号的支配。

进程为什么会被置于 uninterruptible sleep 状态呢？处于 uninterruptible sleep 状态的进程通常是在等待 IO，比如磁盘 IO，网络 IO，其他外设 IO，如果进程正在等待的 IO 在较长的时间内都没有响应，那么就很会不幸地被 ps 看到了，同时也就意味着很有可能有 IO 出了问题，可能是外设本身出了故障，也可能是比如挂载的远程文件系统已经不可访问了，我这里遇到的问题就是由 down 掉的 NFS 服务器引起的。

正是因为得不到 IO 的相应，进程才进入了 uninterruptible sleep 状态，所以要想使进程从 uninterruptible sleep 状态恢复，就得使进程等待的 IO 恢复，比如如果是因为从远程挂载的 NFS 卷不可访问导致进程进入 uninterruptible sleep 状态的，那么可以通过恢复该 NFS 卷的连接来使进程的 IO 请求得到满足，除此之外，要想干掉处在 D 状态进程就只能重启整个 Linux 系统了。

看到有人说如果要想杀掉 D 状态的进程，通常可以去杀掉它的父进程（通常是 shell，我理解的这种情况是在 shell 下直接运行的该进程，之后该进程转入了 D 状态），于是我就照做了，之后就出现了上面的状态：他们的父进程被杀掉了，但是他们的父进程 PID 都变成了1，也就是 init 进程，这下可如何是好？此时我这些D状态的进程已经影响到其他一些进程的运行，而已经无法访问的 NFS 卷又在段时间内无法恢复，那么，只好重新启动了，root 不是玉皇大帝，也有无奈的时候。

跟 czhang 说起这个事，觉得 Linux 如果有这么一个专用的垃圾回收进程就好了：系统自动或者用户手动把僵尸进程，和比如之前我遇到的 D 状态进程的 PPID 设为这个垃圾回收进程，那么通过干掉这个垃圾回收进程来清理这些僵尸们，这样该有多美好…