Nginx通常不出现僵尸进程，因其Master进程显式忽略SIGCHLD信号，使内核自动回收直系子进程（Worker）资源；仅在Worker派生子进程未处理退出、第三方模块失控或Master异常崩溃时可能产生僵尸。
Nginx 的 Master 进程本身并不直接清理僵尸进程，而是通过操作系统信号机制和子进程管理逻辑，间接避免僵尸进程产生。关键在于：Nginx 主动忽略 SIGCHLD 信号，并依赖内核在子进程终止时自动回收其资源——前提是子进程是 Master 的直系子进程且未被其他进程接管。
为什么 Nginx 通常不出现僵尸进程？
Nginx 的 Worker 进程均由 Master 进程 fork() + exec() 直接创建，属于 Master 的子进程。Master 在启动阶段调用：
-
sigemptyset(&set); sigaddset(&set, SIGCHLD); sigprocmask(SIG_BLOCK, &set, NULL);—— 阻塞SIGCHLD - 随后调用
signal(SIGCHLD, SIG_IGN);—— 显式忽略该信号
根据 POSIX 规范，当父进程对 SIGCHLD 设置为 SIG_IGN 时，子进程终止后内核会自动回收其进程表项，不会变成僵尸。这是 Nginx 避免僵尸的核心机制。
什么情况下仍可能出现僵尸？
以下场景可能绕过自动回收机制：
- Worker 进程在运行中又
fork()出子进程（如执行 shell 命令、调用外部程序），而未正确处理子进程退出（未waitpid()或未设SIGCHLD处理） - 使用第三方模块（如某些 Lua 脚本或自定义模块）创建了脱离 Master 管理的子进程链
- Master 进程异常崩溃，但 Worker 仍在运行；此时 Worker 变成 init（PID 1）的子进程，若 init 未及时回收（极少见），短暂僵尸可能存在
如何验证与排查？
可结合系统命令确认实际状态：
-
ps aux | grep 'Z' | grep nginx—— 查看是否有标记为Z（zombie）的 nginx 相关进程 -
ps -eo pid,ppid,stat,comm | awk '$3 ~ /Z/ && $4 ~ /nginx/'—— 精确匹配僵尸及其父进程 PID - 若发现僵尸，检查其 PPID：若为 1，说明原父进程已退出，init 正在接管；若为 Nginx Master PID，说明自动回收失效，需检查是否被覆盖了
SIGCHLD行为
主动干预建议（极少需要）
正常部署下无需干预。仅当确认因模块或脚本导致僵尸时，可：
- 在 Worker 进程中显式设置
signal(SIGCHLD, SIG_DFL)并配合waitpid(-1, &status, WNOHANG)循环回收 - 避免在 Nginx 配置中使用
perl、lua_spawn_process等易产生子进程且不自动回收的指令 - 升级到较新版本 Nginx（1.19.0+），其对子进程生命周期管理更严谨
本质上，Nginx 的设计已将僵尸风险控制在极低水平，问题多源于外围扩展而非核心架构。
