僵尸进程激增导致服务失联，需先用top和ps确认存在，再通过ppid定位父进程，检查其SIGCHLD处理与wait回收逻辑是否缺失或失效。
发现僵尸进程激增，往往不是从日志告警开始，而是服务突然失联——ls失败、ssh拒绝连接、docker run报“Resource temporarily unavailable”。这时别急着重启，先按步骤锁定真凶。
第一步：确认是否真是僵尸进程在作祟
两个命令快速交叉验证：
- 运行
top，看顶部 Tasks 行中 zombie: 后面的数字是否 > 0； - 执行
ps aux | grep 'Z\|defunct'，输出里 STAT 列为Z或 COMMAND 列含<defunct>的，就是僵尸进程。
注意：ps aux | grep Z 容易误匹配命令名带 Z 的进程，务必结合状态列位置或用 awk '$3 ~ /Z/ {print}' 精准筛选。
第二步：顺藤摸瓜，找到该负责的父进程
僵尸本身 kill 不掉，真正要查的是它上面那层“没尽责”的父进程：
- 对任意一个僵尸 PID（比如 12345），运行：
ps -o ppid= -p 12345→ 得到父进程 PID（PPID）； - 再查这个 PPID 的详情：
ps -p <PPID> -o pid,comm,args,etime,stat→ 看命令名（comm）、启动参数（args）、已运行秒数（etime）和当前状态（stat）； - 若 PPID = 1，说明父进程已退出，僵尸已被 init/systemd 接管——此时长期不消失，大概率是容器 init 异常或内核问题；若 PPID 是业务进程（如
node、java、python），就基本锁定了问题源头。
第三步：判断父进程是否具备回收能力
父进程在运行 ≠ 它能正常回收。常见卡点有：
- 信号被屏蔽：检查
cat /proc/<PPID>/status | grep SigBlk，若非零，说明 SIGCHLD 被阻塞； - 没注册信号处理器：父进程未调用
signal(SIGCHLD, handler)或类似逻辑； - handler 里漏了循环回收：只调了一次
waitpid()，但多个子进程同时退出时会漏收； - 用了阻塞式
wait()：导致主线程卡住，无法响应其他事件。
可临时发信号测试：kill -SIGCHLD <PPID>，再观察僵尸是否减少——若无效，说明父进程代码存在硬伤。
第四步：定位到具体代码逻辑缺陷
根据父进程类型，聚焦常见漏洞点：
-
Docker 容器内：主进程是 PID 1（如直接跑
node app.js），它不会自动 wait 子进程。必须加tini或改用支持信号转发的入口； -
Node.js 服务：监听
process.on('SIGCHLD', () => { ... })但没调child_process.waitpid()或没加WNOHANG标志； -
Puppeteer/ChromeDriver 类应用：高频 fork 渲染进程，但主进程未持续轮询回收，或异常退出路径遗漏
waitpid调用； -
Bash 启动脚本：误用
ctrl+z挂起 Java 进程，导致 shell 未收到子进程退出通知，后续也无 wait 逻辑。
关键检查点：所有 fork 出子进程的地方，是否都有对应 wait 回收路径？异常分支（如 try-catch、signal 处理、超时退出）是否全覆盖？
