nginx master进程不支持配置退出信号，仅硬编码响应sigterm、sigquit和sigint触发优雅退出：收到后向worker发送终止指令，等待其处理完现存请求后，master自身才退出。
Nginx 的 Master 进程本身不提供配置项来修改退出信号——它硬编码响应一组标准 Unix 信号，这是由设计决定的，不可通过 nginx.conf 或启动参数更改。
你真正能控制的，是向 Master 进程发送哪个信号，从而触发对应行为。关键不是“配置信号”，而是“选用正确的信号”并确保操作方式符合预期。
哪些信号会触发 Master 退出？
只有以下两类信号会导致 Master 进程最终终止（区别在于是否等待 Worker 完成）：
-
SIGTERM / SIGQUIT：触发优雅退出
- Master 向所有 Worker 发送
SIGQUIT； - Worker 停止 accept 新连接，处理完已有请求后自行退出；
- Master 等待所有 Worker 正常退出后，清理资源、删除 pid 文件，再退出。
- Master 向所有 Worker 发送
SIGINT：行为与
SIGTERM完全一致（Nginx 官方文档明确说明），也是优雅退出。
⚠️ 注意：
SIGKILL（kill -9）会强制杀死 Master，但 Worker 可能变成孤儿进程，不推荐用于正常管理。
如何正确发送退出信号？
推荐使用 Nginx 内置命令，语义清晰、路径安全：
nginx -s quit # 发送 SIGQUIT（推荐） # 或等价于： kill -QUIT $(cat /var/run/nginx.pid)
避免直接用 kill -TERM（虽可用），因为 -s quit 会自动读取正确 pid 文件路径，减少出错可能。
退出过程依赖哪些内部机制？
Master 不是“收到信号就立刻退出”，而是执行一套协作流程：
- 收到
SIGQUIT后，设置内部标志ngx_terminate = 1； - 通过 channel socket 向每个 Worker 发送
NGX_CMD_TERMINATE指令（不是发信号）； - Worker 轮询指令，设
ngx_exiting = 1，停止 accept，逐步清空连接和事件； - Worker 退出时内核发
SIGCHLD给 Master，Master 调用waitpid()回收并确认； - 所有 Worker 状态变为
exited后，Master 执行ngx_master_process_exit()。
这意味着：
✅ 退出是否成功，取决于 Worker 是否能及时完成当前任务；
❌ 如果某个 Worker 卡在长连接或阻塞调用中，Master 会一直等待（无默认超时，但可通过 worker_shutdown_timeout 限制单个 Worker 退出时间）。
常见误操作与规避建议
- ❌ 用
kill -9强杀 Master：Worker 可能残留，监听端口未释放，下次启动报Address already in use； - ❌ 在 reload 或升级过程中并发发
quit：可能导致状态混乱（如旧 Master 尚未完全退出，新进程已启动）； - ✅ 验证退出是否完成：
ps aux | grep nginx # 应只剩 shell 进程，无 master/worker ls /var/run/nginx.pid # 文件应已被删除 tail -n 5 logs/error.log # 查看是否有 "exit" 或 "exiting" 日志
不复杂但容易忽略。
