Linux排查循环嵌套死循环故障，关键是观察进程异常行为：CPU持续100%、响应停滞但不退出、日志刷屏或子进程指数增长；需结合top、ps、strace、SHLVL、ps axjf及调试日志综合定位。
Linux 中排查循环嵌套导致的死循环故障，关键不是盯着“循环语法”本身，而是聚焦在进程行为异常上——比如 CPU 持续 100%、响应停滞但进程不退出、日志疯狂刷屏、或子进程数量指数级增长。这类问题往往不是代码写错了 for 或 while，而是脚本调用链失控（如 A 调 B、B 又 source A）、守护进程反复崩溃重启、或递归逻辑缺乏终止条件。
看进程状态和 CPU 占用
先确认是否真有死循环在运行：
- 运行 top -c，按 P 排序看 CPU 占用最高的进程；若某个 shell 脚本或解释器（bash/python）长期稳居第一且 %CPU 接近 100%，高度可疑
- 用 ps -eo pid,ppid,stat,%cpu,etime,cmd --sort=-%cpu | head -10 查看：STAT 列是否为 R（运行中），ETIME 是否很大但仍在跑，CMD 是否显示重复调用自身（如
/bin/bash ./deploy.sh出现多次） - 对高 CPU 进程执行 strace -p PID -e trace=clone,fork,vfork 2>&1 | head -20，观察是否在高频创建新进程（大量 clone() 成功返回），这是嵌套调用失控的典型信号
查脚本调用链与嵌套深度
Shell 层级本身不提供绝对防护，但 SHLVL 是可信赖的轻量线索：
- 进入疑似脚本所在终端，执行 echo $SHLVL；若值 ≥ 8，基本说明已陷入非预期深层嵌套（正常交互登录一般为 1–3）
- 在脚本开头加入防护逻辑：
if [ "${SHLVL:-1}" -gt "8" ]; then echo "Too deep: SHLVL=${SHLVL}">&2; exit 126; fi - 用 ps axjf | grep -v grep | grep "$(basename "$0")" 查看当前脚本的所有活跃实例及其父子关系，观察是否有闭环结构（如 PID 1234 → 1235 → 1234）
定位具体循环触发点
不要只读源码，要抓运行时证据：
- 对可疑脚本加调试输出：在 while / for 循环体首尾插入 date "+%T.%3N" 和 echo "loop $i"，重定向到临时日志，确认是否无限迭代
- 检查是否误用 exec "$0" "$@" 或 source "$0"，尤其注意没有 guard 条件（如未设标志位避免二次进入）
- 若涉及 systemd 服务，运行 journalctl -u your-service --since "10 minutes ago" | grep -E "(start|fail|exit)"，看是否有密集 restart 记录——这常是服务启动失败后被 Restart=always 不断拉起，每次都在 /tmp 或 /var/run 写又删文件，形成“伪死循环”
区分真实死循环和假象
有些现象看似死循环，实为阻塞或资源耗尽：
- CPU 为 0% 但进程不响应？可能是卡在 read()、accept() 或锁等待，用 strace -p PID 看最后停在哪条系统调用
- 磁盘空间缓慢上涨 + df > du？不是死循环，是小文件堆积或删除后句柄未释放，参考 inotifywait/lsof 定位写入进程
- 日志里反复出现同一行错误（如 “Connection refused”）+ 进程存活？大概率是重试逻辑没加退避，属于业务逻辑缺陷，而非语法级死循环
