先查error.log中“exited on signal”信号值：signal 11为段错误，signal 9为OOM Killer终止，signal 6为主动中止；再结合dmesg确认系统干预、shutdown状态验证、日志写入阻塞排查及第三方模块隔离定位根因。
排查 Nginx 多进程模式下的死锁与异常退出，不能只盯着 error_log 里有没有“deadlock”字眼——Nginx 本身不产生“死锁”日志，所谓“死锁”多是资源阻塞、句柄未释放或进程僵死的误判。真正要抓的是 异常退出信号、残留连接、日志写入失败、系统级干预痕迹 这四类线索，再结合多进程协作机制交叉验证。
看 error.log 中的 signal 退出记录，锁定崩溃类型
Nginx worker 进程非正常终止时，error.log 会明确记录退出信号，这是第一手判断依据：
- exited on signal 11 → 段错误（Segmentation fault），常见于第三方模块 bug、内存越界、未启用模块被调用（如配置了 lua 指令但未编译 --with-http_lua_module）
- exited on signal 9 → 极大概率被系统 OOM Killer 杀掉，需立刻查 dmesg 确认
- exited on signal 6 → abort 调用，多由断言失败触发，常源于严重配置错误（如 worker_rlimit_nofile 超过系统限制却未调 ulimit）或核心模块逻辑异常
- 若带 (core dumped) 字样，说明已生成 core 文件，可 gdb 分析；若无，先检查 ulimit -c 是否为 0 或 kernel.core_pattern 是否指向不可写路径
查 shutdown 状态 worker 是否被误杀，避免人为“制造死锁”
reload 后旧 worker 进入 shutdown 状态是正常行为，它会继续处理已有连接直到自然退出。此时手动 kill -9 它会导致：
- socket 连接未 close，内核报 open socket #xx left in connection yy
- master 日志出现批量 aborting 告警
- 看似“卡住”，实则是人为中断优雅关闭流程
- 验证方式：ps aux | grep 'nginx: worker.*shutdown'，若存在且持续超 5 分钟，先查是否有大文件上传、长轮询或 WebSocket 未断开，而非直接杀进程
确认日志写入是否阻塞，排除磁盘满引发的进程僵死
access.log 或 error.log 瞬间暴涨撑爆磁盘，会导致 Nginx 写日志失败、临时文件无法落盘、worker 进程挂起（表现类似死锁）：
- 执行 lsof +L1 | grep nginx，若输出含 access.log (deleted)，说明日志文件已被 rm 但句柄未释放
- 运行 iostat -x 1 3，观察 %util 是否持续 100%、await 是否 >100ms，确认是否 I/O 阻塞
- 立即释放空间：优先用 nginx -s reload（优雅 reopen 日志文件）；若无效，发 USR1 信号：kill -USR1 $(cat /path/to/nginx.pid)
结合系统日志补全上下文，定位真实根因
error.log 只反映 Nginx “感知到的异常”，真正原因往往在系统层：
- 查 OOM：dmesg -T | grep -i "killed process.*nginx" 或 "out of memory"
- 查资源瓶颈：free -h（内存）、df -h（磁盘）、ss -s（socket 数量）、cat /proc/sys/fs/file-nr（文件句柄使用）
- 查服务状态：systemctl status nginx + journalctl -u nginx -n 100 --no-pager，看启动/退出前后完整链路
- 若怀疑第三方模块，临时注释所有非 core 模块（如 echo、lua、headers-more），仅保留 http、stream 等基础模块测试
