Linux Shell 脚本卡死，通常不是“程序崩溃”，而是陷入阻塞状态——仍在运行，但无响应。核心原因多为等待某个资源、输入或事件，而该条件迟迟不满足。定位关键在于判断脚本停在哪一行、在等什么。
检查进程状态与当前执行点
脚本卡住时，先确认它是否真在运行，以及卡在何处：
- 用 ps aux | grep 脚本名 查看进程是否存在，注意 STAT 列：若显示 D（不可中断睡眠），很可能在等磁盘 I/O 或内核态资源；若为 S（可中断睡眠），通常在等系统调用返回（如 read、wait、sleep）
- 用 strace -p PID 追踪卡住进程的系统调用，输出最后一行即实际阻塞点（例如 read(0, 表示正从标准输入等待数据）
- 对 bash 脚本，可临时加 set -x 并重定向日志（./script.sh 2>debug.log），观察最后执行到哪条命令
常见阻塞场景与应对
以下情况高频导致脚本看似“卡死”：
- 交互式命令未提供输入：如脚本中直接调用 read、ssh（无密钥/无 -o ConnectTimeout）、sudo（需密码但未配置 NOPASSWD）——它们会挂起等待用户键入
- 管道或重定向死锁：例如 cmd1 | cmd2 中，cmd2 缓冲区满且不消费数据，cmd1 写入阻塞；或使用 exec 3>&1 后未正确关闭，导致后续命令 stdout 异常
- 子进程未回收：循环中频繁启动后台任务（cmd &）却不 wait，可能耗尽进程数或产生僵尸，间接影响控制流
- 文件锁或资源竞争：多个实例同时执行并尝试 flock 或访问同一设备（如 /dev/ttyS0），一方持有锁，另一方一直等待
预防性加固写法
避免阻塞不能只靠事后排查，应在编码阶段设防：
- 所有可能交互的命令加超时：timeout 10s ssh user@host cmd、read -t 5 input（5秒无输入则跳过）
- 管道操作慎用，必要时用 stdbuf 控制缓冲（如 stdbuf -oL cmd1 | cmd2 强制行缓存）
- 后台任务统一管理：PIDS="" ; cmd & PIDS="$PIDS $!"，退出前 wait $PIDS
- 敏感资源操作前检查可用性：如 [ -w "$LOCKFILE" ] || exit 1，配合 flock -n 非阻塞加锁
调试辅助技巧
快速缩小问题范围的小方法：
- 用 kill -USR1 PID（bash 支持）触发 shell 打印当前执行栈（需启用 set -o functrace 及自定义 trap）
- 在可疑代码段前后插入 date '+%T.%3N' >&2 记录时间戳，对比间隔定位卡点
- 替换外部命令为模拟版测试：如将 curl 替换为 echo "mock response" > /tmp/curl.out，验证逻辑是否本身健壮
