Nginx 通过 master 进程统一处理信号实现进程管理：HUP 平滑重载、TERM 快速终止、QUIT 优雅退出、USR1 重新打开日志、USR2 热升级；worker 不直接响应信号，异常退出由 CHLD 触发自动拉起；运维使用 nginx -s 封装命令，须向 master PID 发送信号，禁用 kill -9。
Nginx 的信号处理机制是其进程生命周期管理的核心手段，不依赖外部服务管理器（如 systemd），而是通过标准 Linux 信号直接与 master 进程通信，由 master 统一调度 worker 进程的启停、重载和退出行为。
master 进程是信号接收与分发中心
只有 master 进程监听并响应外部信号；worker 进程不直接对外接收信号（手动向 worker 发送信号不被推荐，也无实际管理意义）。master 启动后会注册一系列信号处理函数，将不同信号映射为具体动作：
- HUP（1号）：触发平滑重载——关闭旧 worker、启动新 worker，新 worker 加载更新后的配置，旧连接继续处理直至完成
- TERM 或 INT（15 / 2号）：快速终止——master 立即向所有 worker 发送 TERM 信号，worker 收到后立刻停止接受新请求并退出
- QUIT（3号）：优雅退出——worker 完成当前所有请求后再退出，master 等待全部 worker 正常终止后自身才退出
- USR1（10号）：重新打开日志文件，用于日志轮转（logrotate 场景）
- USR2（12号）：热升级二进制文件（配合 exec + kill 操作实现无缝升级）
信号控制背后的进程协作逻辑
master 并非简单“转发”信号，而是协调整个生命周期状态转换：
- 收到 HUP 时，master 先校验新配置语法，成功后 fork 新 worker，再向旧 worker 发送 QUIT 信号；旧 worker 进入“等待连接结束”状态，新 worker 已开始监听端口并处理新请求
- 收到 QUIT 时，master 向每个 worker 发送 QUIT 信号，并进入等待循环；若某 worker 长时间未退出（如卡在长连接中），master 不会强制杀掉，保持优雅性
- worker 异常退出会触发 CHLD（17号） 信号通知 master，master 自动拉起新 worker 补齐设定数量，保障服务连续性
常用操作对应的信号命令
日常运维中无需记忆编号，Nginx 提供了封装好的 -s 参数接口，本质仍是向 master 进程发送对应信号：
- nginx -s reload → 等价于 kill -HUP `cat /var/run/nginx.pid`
- nginx -s stop → 等价于 kill -TERM `cat /var/run/nginx.pid`
- nginx -s quit → 等价于 kill -QUIT `cat /var/run/nginx.pid`
- nginx -s reopen → 等价于 kill -USR1 `cat /var/run/nginx.pid`
信号安全边界与注意事项
信号机制高效但有明确使用约束：
- 必须向 master 进程 PID 发送信号，不是任意 nginx 进程；可通过 ps -ef | grep nginx 识别 master 行（含 “master process” 字样）
- 避免使用 kill -9，它绕过信号处理逻辑，导致 worker 无法优雅清理资源，可能丢失日志或连接状态
- 配置文件语法错误时，reload 会失败，master 保持原配置运行，不会中断服务
- 非 daemon 模式下（daemon off;），master 进程前台运行，可直接用 Ctrl+C 触发 QUIT 行为
