d状态进程无法被kill -9终止，因其正等待不可中断i/o（如磁盘/nfs响应），需先用ps或/proc/pid/status确认状态，再排查nfs、磁盘、设备等依赖并恢复，禁用kill -9，避免盲目重启。
进程显示 D 状态就是进入了不可中断睡眠，但仅靠 ps aux 看到 D 并不能说明问题严重——关键是要确认它是否“卡住”了。
怎么用 ps 快速筛出 D 状态进程
最直接的方式是过滤 STAT 列含 D 的行：
-
ps aux | awk '$8 ~ /^D/ {print}'—— 只匹配第 8 列（STAT）以D开头的进程（排除D、<code>DN等复合状态） -
ps -eo pid,stat,comm,cmd --sort=-time | grep '^[[:digit:]]\+ D'—— 按运行时间倒序，优先看老的D进程 - 注意：单个
D是正常现象（比如瞬间 I/O 等待），ps刷新间隔内反复出现同一 PID 的D才值得跟进
为什么 kill -9 对 D 状态进程无效
不是命令没发出去，而是内核根本不会把信号递交给处于 TASK_UNINTERRUPTIBLE 状态的进程。该状态的设计初衷就是屏蔽所有外部干扰，确保关键内核路径（如块设备驱动等待硬件响应）不被中断。
-
kill -9发送的是SIGKILL，但进程在内核态阻塞时无法进入信号处理流程 - 强行 kill 不会报错，但
ps中该进程仍显示D，且PID未释放 - 若该进程是用户态发起的系统调用（如
read()）导致的D，通常等 I/O 完成或超时后自动恢复；若由内核线程或驱动缺陷引发，则可能永久卡住
怎么判断 D 进程是不是真卡住了
单看 ps 不够，必须结合上下文定位阻塞点：
- 查内核栈：
cat /proc/<pid>/stack</pid>—— 若输出停在__wait_event、nvme_wait_ready、nfs_wait_on_request等函数，基本锁定阻塞类型 - 查 I/O 压力：
iostat -x 1观察对应磁盘的%util是否持续 100%、await是否远高于平时（如 >100ms） - 查 NFS 挂载：
mount | grep nfs看是否用了hard挂载，再试ls /mnt/badnfs是否卡住 - 查内核错误：
dmesg -T | tail -30找I/O error、timeout、reset、raid5_do_work等关键词
常见诱因和对应处置线索
长期 D 状态几乎总是底层异常的表征，而非进程自身问题：
- 磁盘故障：NVMe SSD 固件卡死、USB 存储掉线、RAID 卡降级 —— 检查
smartctl -a /dev/sdX和cat /proc/mdstat - NFS 服务器无响应：客户端硬挂载 + 网络抖动 → 进程卡在
nfs_wait_on_request—— 临时改用soft,intr,timeo=10重挂载 - 内核驱动缺陷：某些 btrfs 元数据损坏、overlayfs 层叠冲突、定制加密模块 —— 查
lsmod近期加载模块，比对内核更新日志 - 内存直接回收压力：
vm.swappiness=0且zone_reclaim_mode=1时，分配页可能卡在try_to_free_pages—— 调整参数或加内存
真正难处理的不是“怎么杀”，而是“为什么杀不死”——D 状态本身不可怕，可怕的是它背后暴露的硬件、驱动或配置层面的深层异常，这些往往需要重启、换盘、升级固件或调整挂载选项才能根治。
