Nginx Master进程不主动监控Worker实时状态，而是依赖内核在Worker退出时发送SIGCHLD信号，并通过非阻塞waitpid(WNOHANG)及时回收，实现轻量、异步的生命周期管理。
Master 进程并不“主动监控”Worker 状态，而是依靠操作系统内核在 Worker 退出时自动投递 SIGCHLD 信号，并通过轻量、非阻塞的方式及时响应——核心在于“信号驱动 + 非阻塞回收”，而非轮询或心跳。
为什么 SIGCHLD 是关键入口
Worker 进程终止（无论崩溃、被杀、还是优雅退出），内核都会向其父进程（即 Master）发送 SIGCHLD。这个信号是唯一由内核保证送达的异步通知机制，无需 Worker 主动上报，也不依赖网络或共享内存通信。
- 它不区分退出原因：正常 exit()、段错误、被 kill -15 或 kill -9 触发的终止，都会产生该信号
- 它天然支持批量处理：一个信号可能对应多个已退出的 Worker（尤其在高并发 reload 或故障集中发生时）
- 它避免了轮询开销：Master 不需定时调用 waitpid() 查询，只在信号到达时才介入
Master 如何确保不漏收、不阻塞
Nginx 的实现采用“信号屏蔽 + 事件循环集成”的组合策略，兼顾安全与性能：
- 启动初期用 sigprocmask() 阻塞 SIGCHLD，防止 fork() 过程中信号中断导致状态不一致
- 随后调用 signal(SIGCHLD, SIG_IGN) —— 这是最常用且高效的默认做法：内核直接自动回收子进程资源，完全规避僵尸进程
- 若需获取退出状态（如判断是否频繁崩溃），则改用 sigaction() 注册处理函数，并在其中循环调用 waitpid(-1, &status, WNOHANG)
- 该 waitpid() 使用 WNOHANG 标志，确保立即返回，不会挂起 Master 主循环；配合 while 循环可一次性回收所有已终止的 Worker
常见误区与实际表现
很多人误以为 Master 会实时感知 Worker “卡死”或“无响应”，其实它对这类情况完全无感：
- Worker 进入死循环、阻塞在 read() 或 sleep() 中但未退出 → 不发 SIGCHLD → Master 一无所知
- Worker 被 kill -9 终止 → 内核仍发 SIGCHLD → Master 可捕获并重启新 Worker
- Master 自身未忽略 SIGCHLD，又没写信号处理函数 → 子进程变成 Z(zombie) 状态，占用进程表项
- 第三方模块在 Worker 中 fork 出子进程却未 wait → 那些子进程的僵尸由 Worker 负责回收，与 Master 无关
验证与调试建议
可通过系统命令快速确认 SIGCHLD 行为是否生效：
- 执行 ps aux | grep 'Z' | grep nginx：无输出说明无僵尸，SIG_IGN 生效
- 查看 Master 进程的信号掩码：cat /proc/$(cat /var/run/nginx.pid)/status | grep Sig，确认 SigBlk 字段是否包含 SIGCHLD 对应位
- 手动触发一次 reload：nginx -s reload，观察旧 Worker 是否平滑退出、新 Worker 是否正常启动，这是 SIGCHLD 协同 SIGQUIT 的典型链路
