大量 zombie 进程但父进程 pid=1 的 init/systemd 回收问题处理

pid=1 不回收 zombie 是因它们并非孤儿进程，而是父进程存活却未调用 wait()；常见原因包括父进程阻塞、忽略或屏蔽 SIGCHLD，或多线程中信号处理不当。

zombie 进程的父进程是 pid=1，为什么没被回收？

pid=1 的 systemd（或传统 init）本应自动收尸所有孤儿 zombie 进程，但实际中仍见大量 zombie 存在，说明这些进程**并非真正孤儿**——它们的父进程仍是某个用户态进程，只是该父进程没有调用 wait() 或 waitpid() 获取子进程退出状态。pid=1 只接管“父进程已退出”的孤儿进程，不干预“父进程还活着但怠惰”的情况。

常见诱因包括：

• 父进程阻塞在信号处理、锁、I/O 或死循环中，无法响应 SIGCHLD
• 父进程显式忽略了 SIGCHLD（如调用 signal(SIGCHLD, SIG_IGN)），且未手动 wait
• 父进程使用了 sigprocmask() 屏蔽了 SIGCHLD，导致信号积压未被投递
• 多线程程序中，SIGCHLD 被发给非预期线程，而该线程未设置 sigwait() 或 handler

如何定位真正的父进程和它是否在等待子进程？

别只看 ps aux | grep 'Z'，重点查 PPID 和父进程当前状态：

• 执行 ps -eo pid,ppid,stat,comm,args | awk '$3 ~ /Z/ {print $0}'，确认每个 zombie 的 PPID
• 对每个可疑 PPID，运行 ps -o pid,ppid,state,wchan:20,comm -p $PPID，观察其 state（R/S/D/Z）和 wchan（等待内核函数，如 do_wait 表示正在 wait，ep_poll 或空则可能卡住）
• 用 strace -p $PPID -e trace=wait4,waitpid,waitid,rt_sigreturn 2>&1 | head -20 看父进程是否在调用 wait 类系统调用（注意：生产环境慎用，可能影响性能）

若父进程 state == S 且 wchan 是 pipe_wait、ep_poll 或 hrtimer_nanosleep，大概率它正阻塞在别的地方，没轮到处理子进程退出。

systemd 服务中 fork 出的子进程变成 zombie 怎么办？

systemd 默认以 Type=simple 启动服务，此时主进程即为 pid=1 的子进程；若它 fork 出子进程又不 wait，zombie 就会堆积。正确做法是：

• 改用 Type=forking 并确保服务 daemon 正确 double-fork + setsid，让子进程彻底脱离父进程上下文（但需配合 PIDFile=）
• 更推荐 Type=notify 或 Type=exec，并在主进程中主动管理子进程生命周期——例如用 sigaction(SIGCHLD, &sa, NULL) 注册 handler，在 handler 内循环 waitpid(-1, &status, WNOHANG)
• 避免在 systemd service 文件中设 Restart=always 来“掩盖”zombie 问题；这只会让父进程反复重启，zombie 反而更多

注意：systemd 自身不会替你的服务进程调用 wait()，除非该进程已终止（此时子进程才变孤儿，由 pid=1 接管）。

紧急清理 zombie 且无法重启父进程时能做什么？

zombie 本身不占内存/CPU，只消耗一个进程表项，但大量存在可能耗尽 pid_max 或干扰监控。**无法 kill zombie（kill 对 Z 状态无效），也不能强制让 pid=1 收尸非孤儿进程**。唯一可行路径是“唤醒父进程”：

• 向父进程发送 SIGCHLD：kill -s SIGCHLD $PPID —— 若父进程注册了 handler 且未屏蔽该信号，可能触发一次 wait
• 若父进程处于可中断睡眠（state == S），尝试唤醒它依赖的资源：如写入它正在读的 pipe、关闭它等待的 socket、或发 SIGCONT（如果它被 stop）
• 极端情况下，用 gdb -p $PPID 附加后执行 call waitpid(-1,0,0) 强制收尸（需调试符号，且有风险）

真正可靠的解法永远是修复父进程逻辑：确保它不忽略 SIGCHLD、及时响应、在所有退出路径上完成 wait 循环。zombie 是症状，不是病因。