博客

D 状态的就是 uninterruptible sleep ，此时进程不能被信号唤醒，GDB等调试工具也不能对它调试，因为GDB也是用到了信号，也杀不死它，只有系统重启才能消除它。

这篇文件描述了如何利用 /proc/ 目录下的信息来分析进程为何处于D状态：

http://blog.tanelpoder.com/2013/02/21/peeking-into-linux-kernel-land-using-proc-filesystem-for-quickndirty-troubleshooting/

摘要： wchan 即 wait channel ，表示进程阻塞在什么函数上， syscall 列出了阻塞在什么系统调用上。

我的一个用户例子，其实之前已经在/var/log/kern.log 里打印了栈信息，费了很大的劲在/proc/ 里找到的信息已经有了，所以先要看 kern.log 等文件。

用户的分析： 进入 D 状态是因为两次进入了do_exit。 第一次do_exit 调用exit_files 关闭文件, 调用filp_close 时触发了异常， 进入 page_fault 处理流程， 打印完调用栈之后再次调用 do_exit：

由于之前 do_exit 已经将该进程置为 PF_EX ITING 状态,所以进入到 recursive fault 分支，把进程状态置为D。