Nginx Master Process 不处理请求，专责管理 Worker 生命周期：启动时按 worker_processes 指令 fork 子进程，共享监听套接字；通过 waitpid/SIGCHLD 监控 Worker，异常退出即补位；reload 时新旧 Worker 平滑切换；stop（SIGTERM）强制终止，quit（SIGQUIT）触发优雅退出。
Nginx 的 Master Process 不直接处理请求，而是专职负责管理 Worker Process 的生命周期——包括启动、监控、平滑重启与优雅退出。
Master 启动时如何创建 Worker 进程
Master 进程在完成配置解析、信号监听、共享内存初始化等准备工作后，会根据 worker_processes 指令（如设为 auto 或具体数值）fork 出对应数量的 Worker 子进程。每个 Worker 都继承了 Master 已准备好的监听套接字（通过 SO_REUSEPORT 或 accept mutex 协作避免惊群），但拥有独立的事件循环和内存空间。
- Worker 进程是单线程、事件驱动的，不使用多线程模型
- Master 不向 Worker 传递连接，而是由所有 Worker 竞争接收新连接（默认启用 accept_mutex，可关闭）
- fork 后，Worker 关闭不需要的文件描述符（如监听 socket 的写端、Master 的通信 pipe 等）
Master 如何监控和维持 Worker 健康
Master 通过操作系统级别的子进程状态跟踪（waitpid + SIGCHLD）持续监听 Worker 的退出信号。一旦某个 Worker 异常终止（如段错误、被 kill -9），Master 会立即 fork 一个新的 Worker 补位，保持预设进程数不变。
- Worker 崩溃时，Master 日志中会出现类似
"worker process [PID] exited on signal 11" - 正常退出（如收到 SIGQUIT）不会触发补位；异常退出（SIGSEGV/SIGBUS/SIGKILL 等）才会重建
- 可通过
worker_rlimit_core和working_directory配合生成 core dump 用于调试
平滑升级（reload）时的生命周期切换
执行 nginx -s reload 或发送 SIGHUP 时，Master 会重新加载配置，然后 fork 新 Worker，并通知旧 Worker 逐步退出：先停止接受新连接，待已有连接处理完毕后自行退出（即 graceful shutdown）。
- 旧 Worker 进入
NGX_SHUTDOWN状态，不再调用accept()，但继续处理已建立的连接 - 新 Worker 启动后立即开始 accept 新连接，实现零停机切换
- 旧 Worker 完全退出后，Master 才真正清理其资源；若长时间不退，可用
kill -USR2强制终止（不推荐）
安全关闭（stop）与优雅退出（quit）的区别
发送 TERM（nginx -s stop）会令 Master 立即向所有 Worker 发送 SIGTERM，Worker 强制终止——可能中断正在处理的请求；而 QUIT（nginx -s quit）则触发优雅退出流程：Worker 拒绝新连接、等待现有请求结束后再退出。
-
SIGTERM→ Worker 立即退出（不等请求完成） -
SIGQUIT→ Worker 进入 graceful shutdown，最多等待worker_shutdown_timeout（默认未设限，依赖应用层超时） - Master 收到所有 Worker 退出确认后，自身才终止
