nginx master进程仅将自身pid写入master.pid文件作为信号锚点，不持久化任何运行状态；该文件被误删或篡改会导致信号操作失效；多实例需隔离pid路径以防冲突。
Nginx 的 Master 进程本身不实现进程状态的持久化，它只做一件事：把自己的 PID 写进一个文件，并且仅此而已。
这个文件就是 master.pid（默认路径如 /var/run/nginx.pid 或 /usr/local/nginx/logs/nginx.pid），它的作用非常明确——为外部提供一个可寻址的控制入口，不是状态快照，也不记录运行时全貌。
master.pid 文件的本质是“信号锚点”，不是状态数据库
- Master 启动后，将自身 PID 写入该文件，仅此一次（除非重载或重启）；
- 它不写入 Worker、Cache Loader、Cache Manager 等任何子进程 PID；
- 不跟踪进程健康状态、连接数、请求计数、内存使用等运行指标；
- 不在崩溃或异常退出后自动重建该文件（需手动重启或执行
nginx -s reload才会刷新）； - 若文件被误删、内容被篡改、或指向已不存在的 PID，会导致
kill、nginx -s等操作失效甚至误杀其他进程。
真正的“状态”靠操作系统和外部工具维持
Nginx 自身不维护状态，但可通过以下方式间接支撑可观测性与恢复能力：
- 使用
ps --ppid $(cat /var/run/nginx.pid)查看直属子进程（依赖内核进程树，非 Nginx 主动同步）； - 结合
systemctl status nginx（systemd 环境下）读取服务单元状态、启动时间、上次失败原因等元信息； - 通过
nginx -t验证配置有效性，避免因配置错误导致 Master 启动失败； - 在容器或编排平台中，用 liveness probe 检查
curl -I http://localhost/healthz或监听端口连通性，替代对 PID 文件的强依赖。
多实例部署必须隔离 PID 文件路径
- 若同一台机器跑多个 Nginx 实例（如不同站点、灰度环境），每个实例的
pid指令必须指向唯一路径：pid /var/run/nginx-site-a.pid;
- 否则 PID 文件冲突，信号会发错目标，造成意外交互或服务中断。
不复杂但容易忽略。
