详解日志记录中的 "worker process exited on signal"：如何排查 Core Dump-Nginx-PHP中文网

“worker process exited on signal”是nginx worker进程崩溃的结果而非原因，需结合core dump（linux下启用ulimit -c unlimited并查/proc/sys/kernel/core_pattern；windows下查事件查看器application error日志）与gdb堆栈分析（bt full）定位真实缺陷，常见于第三方模块、内存越界或php-fpm通信中断。

$详解日志记录中的 \$

“worker process exited on signal” 是 Nginx 日志中一个关键告警，表明某个 worker 进程非正常终止，通常由操作系统发送的信号（如 SIGSEGV、SIGABRT）触发。它本身不是错误原因，而是崩溃结果的提示。真正要定位问题，必须结合 Core Dump（核心转储）与系统级日志协同分析——尤其在 Windows 或 Linux 环境下，生成和读取方式差异极大。

Windows 下：别查 nginx.log，盯紧事件查看器

在 phpEnv 或其他 Windows 版 Nginx 环境中，Core Dump 文件默认不生成，Windows 不支持传统 Linux 风格的 core.* 文件。崩溃线索唯一可靠来源是：

按下 Win + R，输入 eventvwr.msc 打开事件查看器
左侧导航至 Windows 日志 → 应用程序
筛选来源为 Application Error 或 Windows Error Reporting
查找时间点与 Nginx 退出吻合的条目，重点关注字段：
• 故障模块名称（如 php7.dll、ngx_http_lua_module.dll、nginx.exe）
• 异常代码（如 0xc0000005 对应访问违规，常等价于 SIGSEGV）

同时检查 logs/error.log 是否有 recv() failed (10054: An existing connection was forcibly closed...) ——这大概率说明 PHP-FPM 已先崩溃，Nginx worker 在通信时被连带拖垮。

Linux 下：确认 core dump 开关并定位文件位置

Linux 默认可能禁用 Core Dump，需主动启用：

执行 ulimit -c 查看当前限制；若返回 0，表示关闭
临时开启：ulimit -c unlimited
永久生效：将该命令加入 /etc/security/limits.conf 或服务启动脚本中
确认内核配置：cat /proc/sys/kernel/core_pattern
• 若为 core 或 core.%p，dump 文件通常在进程工作目录
• 若为 |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h（常见于 systemd 系统），则 dump 存于 /var/lib/systemd/coredump/，且多为 .xz 压缩格式

注意：Nginx worker 崩溃时，实际生成的是 nginx 主进程或其子进程的 core 文件，而非 PHP-FPM 的——除非你明确对 php-fpm 进行了调试配置。

用 gdb 分析 core 文件：关键三步

拿到 core 文件后，需匹配**完全一致版本**的 nginx 可执行文件（含调试符号）才能有效回溯：

运行 gdb /path/to/nginx /path/to/core
输入 bt full 查看完整堆栈（含寄存器、局部变量）
重点观察：
  • 崩溃点是否落在第三方模块（如 lua、perl、njs）内
  • 是否调用了已卸载的共享库（dlclose 后仍访问）
  • 是否出现空指针解引用、数组越界、use-after-free 等典型内存错误

若无调试符号，bt 只显示地址，此时需提前保留编译时的 .debug 包，或使用 addr2line -e nginx -f -C [address] 辅助定位。

绕过 core dump 的快速验证法

当无法生成或获取 core 文件时，可用以下方法缩小范围：

逐个禁用可疑模块：注释掉 nginx.conf 中的 load_module 行（如 ngx_http_lua_module.so），再 nginx -t && nginx -s reload
降低并发压力：临时设 worker_processes 1; 和 worker_connections 1024;，排除资源竞争类问题
切换 PHP 运行模式：从 php-fpm 改为 php-cgi（spawn-fcgi），观察是否仍崩溃——可判断问题是否出在 FPM 通信层
检查 shared memory 使用：如使用 lua_shared_dict 或 limit_req_zone，过大或未清理的共享内存可能导致 worker 初始化失败