Master进程不实时监控Worker状态，仅通过SIGCHLD信号和非阻塞waitpid()感知其退出事件并重启；无法发现卡死或无响应Worker，控制依赖Unix信号，真实状态需外部工具获取。
Master 进程本身不实时监控 Worker 的运行状态，比如 CPU、内存、响应延迟或是否卡死。它只感知 Worker 是否退出，并在必要时拉起新进程。
靠 waitpid() 和 SIGCHLD 捕获退出事件
Master 启动 Worker 后，并不轮询或心跳探测，而是通过系统调用 waitpid() 配合 SIGCHLD 信号来获知子进程终止：
- 当 Worker 因崩溃、被 kill 或优雅退出时，内核向 Master 发送 SIGCHLD
- Master 在信号处理函数或事件循环中调用 waitpid(-1, &status, WNOHANG)，获取退出的 PID 和状态码（如 exit code 或终止信号）
- 若退出非预期（如频繁段错误），Master 会按 worker_processes 数量补足新 Worker
无法发现卡死、阻塞或无响应的 Worker
Worker 若陷入长时间阻塞（如 DNS 超时、上游 connect hang、Lua 死循环），只要没退出，Master 就完全不知情：
- Worker 不主动上报任何状态，也不与 Master 建立通信通道
- 没有内置健康检查机制，Master 不会发送 ping 或等待响应
- 这种设计换来轻量和稳定，但也意味着必须依赖外部手段识别“假存活”
控制靠信号，不是状态反馈
Master 对 Worker 的所有操作都通过标准 Unix 信号完成，Worker 收到即执行，不返回结果：
- SIGHUP：触发 reload，启动新 Worker，通知旧 Worker 开始优雅关闭
- SIGTERM / SIGQUIT：要求 Worker 退出（前者快速，后者等待连接完成）
- SIGUSR1：重开日志文件，常用于日志切割
- SIGUSR2 + SIGWINCH：配合完成二进制热升级
真实状态得靠外部工具查
要了解 Worker 当前是否在工作、占多少内存、处理多少连接，必须绕过 Master，直接看系统或加监控：
- 用 ps -C nginx -o pid,ppid,rss,comm --sort=-rss 查每个 Worker 的内存和父子关系
- 用 ss -tnlp | grep :80 确认端口是否仍在监听、worker 是否实际承接连接
- 用 curl -I http://127.0.0.1/healthz 做 HTTP 探活，验证服务真实可用
- 接入 Prometheus + nginx-vts-module 或 OpenResty + Lua，采集请求数、5xx、活跃连接等指标
