在 linux 系统中，当进程由于网络或磁盘等 i/o 问题而卡住时，通常会进入不可中断睡眠状态（uninterruptible sleep），在 ps 命令中显示为 d 状态。这是因为这些进程正处于内核态的系统调用中，无法立即响应信号，包括 kill -9。
当使用 ps 查看进程列表时，可以看到卡住的进程状态显示为 D。
根据 man ps 的描述，D 状态表示进程处于不可中断睡眠状态。这种状态的进程无法立即处理任何发送给它的信号，因此无法通过 kill 命令终止。
Linux 进程有两种睡眠状态：
Interruptible Sleep（可中断睡眠），在 ps 命令中显示为 S。这种状态的进程可以通过发送信号来唤醒。Uninterruptible Sleep（不可中断睡眠），在 ps 命令中显示为 D。这种状态的进程无法立即处理任何信号，这就是为什么 kill 命令无法终止它们的主要原因。
在 Stack Overflow 上有一个相关的解答，指出 D 状态的进程通常是处于某个内核态的系统调用中。要确定是哪个系统调用以及在等待什么，可以通过 Linux 下的 procfs（即 /proc 目录）查看进程的当前内核调用栈。
通过模拟 JuiceFS 客户端进程（因为 JuiceFS 基于 FUSE，是用户态的文件系统，容易模拟 I/O 故障），我们可以看到 ls 命令卡在了 vfs_fstatat 调用上，这会向 FUSE 设备发送 getattr 请求，并等待回应。如果 JuiceFS 客户端进程被暂停，ls 命令就会卡住。
$ cat /proc/`pgrep ls`/stack[] request_wait_answer+0x197/0x280[] __fuse_request_send+0x67/0x90[] fuse_request_send+0x27/0x30[] fuse_simple_request+0xcc/0x1a0[] fuse_do_getattr+0x120/0x330[] fuse_update_attributes+0x68/0x70[] fuse_getattr+0x3d/0x50[] vfs_getattr_nosec+0x2f/0x40[] vfs_getattr+0x26/0x30[] vfs_fstatat+0x78/0xc0[] SYSC_newstat+0x2e/0x60[] SyS_newstat+0xe/0x10[] entry_SYSCALL_64_fastpath+0x22/0xcb[] 0xffffffffffffffff
在这种情况下，按 Ctrl+C 无法退出，但使用 strace 可以唤醒进程并处理之前的中断信号，使其退出。
root@localhost:~# strace -p `pgrep ls`strace: Process 26469 attached--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---rt_sigreturn({mask=[]}) = -1 EINTR (Interrupted system call)--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=13290, si_uid=0} ---rt_sigreturn({mask=[]}) = -1 EINTR (Interrupted system call)...tgkill(26469, 26469, SIGINT) = 0--- SIGINT {si_signo=SIGINT, si_code=SI_TKILL, si_pid=26469, si_uid=0} ---+++ killed by SIGINT +++
如果使用 kill -9，也可以终止进程，因为 vfs_lstatat() 等简单的系统调用并没有屏蔽 SIGKILL、SIGQUIT、SIGABRT 等信号。
在更复杂的 I/O 错误模拟中，给 JuiceFS 配置一个无法写入的存储类型，并挂载后，使用 cp 尝试写入数据，cp 也会卡住。
root@localhost:~# cat /proc/`pgrep cp`/stack[] request_wait_answer+0x197/0x280[] __fuse_request_send+0x67/0x90[] fuse_request_send+0x27/0x30[] fuse_flush+0x17f/0x200[] filp_close+0x32/0x80[] __close_fd+0xa3/0xd0[] SyS_close+0x23/0x50[] entry_SYSCALL_64_fastpath+0x22/0xcb[] 0xffffffffffffffff
cp 卡在 close_fd() 是因为 JuiceFS 的写入操作是异步的，当 cp 调用 write() 时，数据会先缓存在 JuiceFS 客户端进程中，并异步写入后端存储。cp 完成写入后会调用 close 确保数据写入完成，对应 FUSE 的 flush 操作。如果后端存储写入失败，flush 操作会卡住，导致 cp 也卡住。
在这种情况下，按 Ctrl+C 或使用 kill 可以中断 cp 的运行，因为 JuiceFS 实现了文件系统操作的中断处理，让它放弃当前操作（如 flush），返回 EINTR，从而在遇到网络故障时中断访问 JuiceFS 的应用。
如果停止 JuiceFS 客户端进程，使其无法处理任何 FUSE 请求（包括中断请求），则无法通过 kill -9 终止进程，进程状态会变为 D 状态。
root 1592 0.1 0.0 20612 1116 pts/3 D+ 12:45 0:00 cp parity /jfs/aaa
此时，可以通过 cat /proc/1592/stack 查看进程的内核调用栈：
root@localhost:~# cat /proc/1592/stack[] request_wait_answer+0x12d/0x280[] __fuse_request_send+0x67/0x90[] fuse_request_send+0x27/0x30[] fuse_flush+0x17f/0x200[] filp_close+0x32/0x80[] __close_fd+0xa3/0xd0[] SyS_close+0x23/0x50[] entry_SYSCALL_64_fastpath+0x22/0xcb[] 0xffffffffffffffff
内核调用栈显示进程卡在 FUSE 的 flush 调用上。只要恢复 JuiceFS 客户端进程，就可以立即中断 cp 并使其退出。
像 close 这种涉及数据安全性的操作是不可重启的（non-restartable），因此不能被 SIGKILL 等信号随意中断，必须由 FUSE 实现端响应中断操作才能中断。
因此，只要 JuiceFS 客户端进程能够健康响应中断，就不必担心访问 JuiceFS 的应用会卡死。或者，可以通过终止 JuiceFS 客户端进程来结束当前挂载点，中断所有正在访问该挂载点的应用。
以上就是Linux 进程卡住了怎么办？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/15752.html
微信扫一扫 
支付宝扫一扫 
