Nginx Master进程仅通过master.pid文件持久化自身PID，不管理全局PID或Worker等子进程PID；该文件仅用于外部信号控制，非状态中心，也不由Nginx自动维护。
Nginx 的 Master 进程并不直接“管理全局 PID”，而是负责创建、监控和协调 Worker 进程，并通过一个固定的 master.pid 文件持久化记录自身的进程 ID，供外部（如管理员、脚本、systemd）识别和控制主进程。
Master 进程只维护自身 PID，不跟踪所有子进程
Master 进程启动后，会将自己的 PID 写入配置中指定的 pid 文件（默认为 /usr/local/nginx/logs/nginx.pid 或 /var/run/nginx.pid）。该文件仅保存 Master 的 PID，不包含 Worker、Cache Manager、Cache Loader 等其他子进程的 PID。Nginx 不维护一个“全局 PID 列表”或进程注册表。
- Worker 进程由 Master
fork()创建，但其 PID 仅存在于内核进程表中，Master 不显式存储或同步这些值； - 可通过
ps --ppid <master-pid></master-pid>查看直属子进程，但这是 Linux 内核提供的视图，非 Nginx 主动管理； - 热重载（
nginx -s reload）时，Master 会启动新 Worker 并优雅关闭旧 Worker，但仍只更新自身 PID 文件，不写入新 Worker 的 PID。
PID 文件是控制入口，不是状态中心
master.pid 的核心作用是让信号操作有明确目标：比如 kill $(cat /var/run/nginx.pid) 发送信号给 Master 进程，从而触发 reload、stop、quit 等动作。它不反映运行时全貌，也不用于内部调度。
- 若手动删除该文件，Nginx 不会自动重建（除非重启或执行
nginx -s reload）； - 若文件被篡改或指向错误 PID，会导致信号误发，甚至 kill 错误进程；
- 多实例部署时，必须为每个实例配置独立的 pid 路径，否则 PID 文件冲突。
Worker 进程无独立 PID 文件，依赖 Master 统一调度
Nginx 设计上避免 Worker 自行维护标识。所有生命周期操作（启停、升级、平滑退出）均由 Master 进程统一决策并驱动：
- Master 通过进程间通信（如 socketpair、eventfd）与 Worker 协作，而非通过读取其 PID；
- Worker 异常退出时，Master 从 waitpid() 获取退出状态，并按配置决定是否拉起新进程（
worker_processes auto下默认重启）； - 日志中的 “worker process XXXX exited” 消息来自 Master 的 wait 监听，不是 Worker 主动上报。
实际运维中应关注的 PID 相关行为
理解 PID 管理方式有助于正确排查和操作：
- 检查服务是否运行：优先用
systemctl status nginx或pgrep -f "nginx: master"，而非仅依赖 pid 文件存在； - 强制终止：先
kill -TERM $(cat /var/run/nginx.pid)尝试优雅停止，超时再kill -KILL； - 容器化部署时，确保 pid 文件路径可写且不被 volume 覆盖，或在 entrypoint 中禁用（
pid /dev/stdout不生效，应设为pid /tmp/nginx.pid并挂载临时目录）； - 自定义 init 脚本需读取 pid 文件前加判断：
[ -s /var/run/nginx.pid ] && kill -0 $(cat /var/run/nginx.pid) 2>/dev/null验证进程是否存活。
