nginx master进程通过接收并解析操作系统信号实现控制操作：sighup触发平滑重载，sigterm快速终止，sigquit优雅退出，sigusr1重开日志，sigusr2热升级；所有信号须发给master pid，由其统一调度worker生命周期。
Nginx 的 Master 进程本身不处理控制台命令请求，它只响应操作系统发送的信号（signal）。所谓“控制台命令”，比如 nginx -s reload 或 kill -HUP <pid></pid>，本质上都是用户通过 shell 发起的操作，最终被转换为向 Master 进程发送特定信号——Master 收到后解析并执行对应动作。
这不是传统意义上的“请求-响应”通信，而是一种基于 Unix 信号机制的异步通知方式。
Master 进程如何响应各类控制操作
nginx -s start/nginx
启动时，主程序直接 fork 出 Master 进程，由它完成配置加载、监听套接字创建、Worker 派生等初始化工作。这不是运行时命令，而是启动入口。nginx -s stop或kill -TERM <pid></pid>
Master 收到SIGTERM信号后，立即向所有 Worker 进程发送SIGQUIT，然后自身退出。Worker 收到SIGQUIT后立刻终止，不等待当前请求完成（即“快速关闭”）。nginx -s quit或kill -QUIT <pid></pid>
Master 收到SIGQUIT后，向 Worker 发送SIGQUIT；Worker 会先完成正在处理的请求，再退出（即“优雅关闭”）。Master 等待所有 Worker 退出后，自身也退出。-
nginx -s reload或kill -HUP <pid></pid>
Master 收到SIGHUP后：- 重新读取并校验
nginx.conf - 若配置合法，则 fork 新一批 Worker 进程
- 向旧 Worker 发送
SIGQUIT，让它们逐步退出 - 新 Worker 开始接受新连接，实现零中断重载
- 重新读取并校验
nginx -s reopen或kill -USR1 <pid></pid>
Master 收到SIGUSR1后，重新打开access.log和error.log文件句柄（常用于日志轮转后刷新写入目标）。nginx -s reload不等于重启进程
它不 kill -9 Master，也不重新 exec nginx 二进制，只是让 Master 主动触发配置重载流程，整个过程无服务中断。
控制命令背后的信号映射关系
| 命令示例 | 实际发送信号 | Master 行为 |
|---|---|---|
nginx -s stop |
SIGTERM |
终止所有 Worker，自身退出 |
nginx -s quit |
SIGQUIT |
通知 Worker 优雅退出，自身等待后退出 |
nginx -s reload |
SIGHUP |
校验配置、启新 Worker、停旧 Worker |
nginx -s reopen |
SIGUSR1 |
重新打开日志文件 |
nginx -s upgrade |
SIGUSR2 |
启动新版本 Nginx 进程，移交监听端口 |
注意：所有这些信号都只能发给 Master 进程 PID（通常存于
/var/run/nginx.pid），发给 Worker 进程无效或行为不同（例如 Worker 收到SIGUSR1也会 reopen 日志，但不推荐这么做）。
如何确认命令是否生效
- 查看进程状态：
ps aux | grep nginx，观察 Worker 数量是否变化、是否有新旧进程共存 - 检查错误日志：
tail -f /var/log/nginx/error.log，重载失败时会有明确报错 - 验证配置语法：
nginx -t，避免reload因配置错误失败导致服务中断
Master 的设计就是“静默守候 + 快速响应信号”，它不监听网络端口、不解析命令行参数（除启动阶段）、不维护连接，纯粹靠信号驱动全局行为。这种机制轻量、可靠，也正因如此，Nginx 才能保持极低的管理开销和高稳定性。
