nginx中master进程通过信号（如sighup、sigquit）控制worker，而非管道；管道仅用于worker异常退出时单向回传状态码，是辅助机制。
Nginx 中 Master 进程并不通过管道向 Worker 进程发送运行指令或控制命令。这是一个常见误解。真正用于下发 reload、quit、reopen 等操作的是信号（signal），不是管道。
管道在 Nginx 里确实存在，但它只承担一个非常有限、单向、被动的角色：Worker 进程异常退出时，把退出状态码回传给 Master。它不承载配置、不传输指令、不支持交互式控制。
Master 和 Worker 的通信机制其实是“信号 + 辅助管道”组合
-
信号是主控手段
Master 收到SIGHUP（reload）、SIGQUIT（优雅退出）、SIGTERM（强制终止）等信号后，会：- 解析意图（比如 reload 就要加载新配置）
- 启动新 Worker（如果需要）
- 向旧 Worker 发送
SIGQUIT或SIGTERM - 不通过管道“发命令”，而是直接调用
kill()系统调用
-
管道只是状态回传通道
每个 Worker 启动时，Master 会用socketpair()创建一对 Unix 域字节流套接字（即所谓 channel），并把其中一端传给 Worker。约定如下：- Worker 关闭写端，只保留读端 → 等待从管道读取数据（实际极少读）
- Master 关闭读端，只保留写端 → 仅在 Worker 异常崩溃退出时，Worker 自己往管道写一个状态码（如
128 + SIGSEGV），让 Master 知道它为何挂了
注意：这个管道不是 Master 用来“发命令”的通道。Worker 也不会监听它来接收业务指令。
那 Worker 是怎么响应 reload / quit 的？
Worker 进程本身会注册信号处理器（如 ngx_signal_handler），当收到 SIGQUIT 时：
- 停止接受新连接
- 处理完当前请求后自行退出
- 退出前，可能通过已有的 channel 管道向 Master 报告退出码（可选）
整个过程不需要 Master 主动往管道写任何指令。
为什么有人误以为“Master 用管道发命令”？
因为源码中确实有 ngx_write_channel() 函数，并且 NGX_CMD_QUIT 这类宏也存在。但这些命令仅用于Worker 之间通信，或极少数内部协调场景（例如多个 Worker 协同关闭监听句柄），不用于 Master 控制 Worker 的生命周期。
典型用法包括：
- Worker A 想通知 Worker B “我准备退出，请你接管某个共享资源”
- Master 在启动新 Worker 后，用
NGX_CMD_OPEN_CHANNEL让所有现存 Worker 知道新成员加入，以便后续 Worker 间直连通信
这些都属于辅助性、非核心控制路径，不影响主流程。
总结关键点
- Master 控制 Worker 的方式是：接收外部信号 → 执行逻辑 → 向 Worker 发送操作系统信号
- 管道（channel）作用是：Worker 主动上报异常退出状态，单向、只写、低频
-
ngx_channel_t结构和NGX_CMD_*命令主要用于 Worker 间协作，不是 Master 的遥控器 - 所有
nginx -s reload、kill -HUP $(cat nginx.pid)的本质，都是发信号，不是写管道
不复杂但容易忽略：信号才是 Nginx 进程控制的脊柱，管道只是后台默默记账的小本子。
