Nginx Worker 进程退出后由 Master 自动补足：Master 通过 SIGCHLD 信号实时感知退出，调用 waitpid 非阻塞回收，依退出原因（正常/异常）决定是否重启；新 Worker 继承 socket、加载配置、校验就绪后纳入管理。
Worker 进程退出后，Nginx 不会放任空缺，而是由 Master 进程实时检测、判断原因，并按需拉起新进程补足数量——这个过程不依赖外部干预，完全自动完成。
Master 如何发现 Worker 退出
Master 不靠轮询或定时扫描，而是利用操作系统信号机制：当任意 Worker 终止时，内核会向其父进程（即 Master）发送 SIGCHLD 信号。Master 在启动时已通过 sigaddset(&set, SIGCHLD) 显式监听该信号，并在事件循环中调用 sigsuspend() 挂起等待。一旦收到 SIGCHLD，便立即进入回收逻辑。
- 调用
waitpid(-1, &status, WNOHANG)非阻塞获取已退出子进程 PID 和退出状态 -
WNOHANG确保不会卡住，即使没有子进程退出也立刻返回，保障 Master 响应其他信号（如 SIGHUP、SIGTERM）的实时性 - 若返回值 > 0，说明有 Worker 退出；返回 0 表示无子进程终止；返回 -1 且 errno == ECHILD 则表示无子进程可回收
退出原因判断与差异化处理
Master 解析 status 中的退出码和终止信号，区分是“主动退出”还是“异常崩溃”，从而决定是否重启：
- 正常退出（如收到 SIGQUIT 后优雅关闭）：exit code 为 0，Master 记录日志但不拉起新进程——因为 reload 或 quit 操作本就预期 worker 数量暂时减少
- 异常退出（如被 SIGTERM 强杀、段错误、OOM killer 干掉）：exit code 非 0 或 signal 不为 0（如 SIGSEGV、SIGKILL），Master 立即调用
ngx_start_worker_process()fork 新 Worker - 配置中若设
worker_processes auto;，Master 会严格维持 CPU 核数个 Worker；若为固定数值（如worker_processes 4;），则始终补足至该数
新 Worker 的启动与就绪保障
拉起新 Worker 不是简单 fork 就完事，而是一套带校验与容错的初始化流程：
- 继承 Master 已建立的监听 socket 文件描述符，无需重新 bind/listen，避免端口冲突
- 加载当前生效的配置（包括 reload 后的新配置，或原配置），执行内存分配、连接池初始化等步骤
- 若初始化失败（如配置语法错误、共享内存不足），新 Worker 会快速退出，Master 捕获后记录 error.log，但不会影响旧 Worker 继续服务
- 只有新 Worker 成功进入事件循环并开始 accept 连接，才算真正就绪；Master 会将其纳入内部进程列表统一管理
常见场景下的行为表现
实际运行中，不同退出触发方式对应不同行为模式：
-
nginx -s quit→ Master 发送 SIGQUIT 给所有 Worker，它们优雅退出；Master 不补进程，最终只剩 Master 自身 -
nginx -s stop→ Master 发送 SIGTERM，Worker 强制终止；Master 检测到后不补进程，直接退出 - Worker 因 bug 崩溃 → Master 立即 fork 新进程，整个过程毫秒级，业务请求几乎无感知
- 系统内存耗尽触发 OOM killer → 内核 kill -9 Worker，Master 捕获 SIGCHLD 后拉起新进程，同时 error.log 记录 “worker process XXX exited on signal 9”
