Nginx工作进程Worker在处理异常信号时的堆栈记录-Nginx-PHP中文网

Nginx worker崩溃时默认不生成core dump或堆栈，需配置ulimit、core_pattern、--with-debug及error_log debug，并配合gdb或systemd-coredump分析。

nginx工作进程worker在处理异常信号时的堆栈记录

Nginx 的 worker 进程在接收到某些异常信号（如 SIGSEGV、SIGABRT、SIGFPE 等）时，默认不会自动打印堆栈信息，也不会生成 core dump，因此排查崩溃类问题往往缺乏直接线索。要获取崩溃时的调用栈，需主动配置系统与 Nginx 本身的行为。

worker 进程崩溃时，只有生成有效的 core 文件，才能用 gdb 分析堆栈。但默认情况下，Linux 对非 root 进程、或受限制的容器环境会禁用 core dump。

检查并提升 core 文件大小限制：ulimit -c unlimited（需在启动 Nginx 前执行，或写入 systemd service 的 LimitCORE=infinity）
设置 core 文件保存路径和命名格式，例如在 /etc/sysctl.conf 中添加：
kernel.core_pattern = /var/log/nginx/core.%e.%p.%t
确保目标目录存在、有写权限，且文件系统未挂载为 noexec 或 nosuid

Nginx 自身不内置崩溃时的堆栈打印功能，但可通过以下方式增强可观测性：

编译时开启调试支持：--with-debug，并确保链接了 libbacktrace（较新版本 GCC 自带），部分定制 build 可在 SIGSEGV 处理器中插入简易 backtrace 输出（需修改源码 src/os/unix/ngx_process.c 中的 ngx_signal_handler）
使用 gdb --pid $(pgrep nginx) 附加运行中 worker，在复现问题前设断点或捕获信号：handle SIGSEGV stop print
配合 systemd-coredump（若使用 systemd）：启用后，崩溃时自动收集 core + 元数据，运行 coredumpctl info nginx 即可查看简要堆栈

即使没有 core，Nginx error log 仍可能提供关键上下文：

确保 error_log /var/log/nginx/error.log debug; 已开启（debug 级别会记录进程信号接收、模块初始化、事件循环状态等）
注意日志中类似 signal 11 (SIGSEGV) received 或 abort() called 的行，结合时间戳与 worker PID 定位对应 core 文件
若使用第三方模块（如 Lua、njs、动态共享库），优先检查其是否触发非法内存访问；可临时禁用模块验证是否为根本原因

为确认配置生效并稳定捕获堆栈，建议做最小闭环验证：

写一个故意崩溃的 location（仅测试环境！）：
location /crash { return 500; add_header X-Crash "yes"; # 然后用 Lua 模块调用 ngx.exit(0) 后再访问非法指针 }
用 kill -SEGV $(pgrep -f "nginx: worker") 主动发送信号，观察是否生成 core 并被正确捕获
用 gdb /usr/sbin/nginx /var/log/nginx/core.nginx.* -ex "bt full" -ex quit 批量提取堆栈