worker_rlimit_core仅设置worker进程core文件大小软限制，不指定路径；真正决定物理路径的是kernel.core_pattern，需配合systemd limitcore、ulimit -c及目录权限共同生效。

worker_rlimit_core 是 Nginx 配置指令，但它本身并不开启或控制 Core Dump 的物理路径记录——这是一个常见误解。该指令仅用于向 Nginx worker 进程传递 ulimit -c 限制值（即允许生成的 core 文件大小上限），而真正的物理路径、文件名、是否写入、能否成功落地，完全由操作系统内核和运行环境决定，与 Nginx 配置无关。

下面分三部分讲清楚关键点和实操路径：

一、worker_rlimit_core 的真实作用与用法

它只做一件事：在 Nginx 启动时，为每个 worker 进程调用 setrlimit(RLIMIT_CORE, ...) 设置 core 文件大小软限制。

• 若设为 0：等效于 ulimit -c 0 → 禁止生成任何 core 文件（即使系统其他配置都开了，也无效）。
• 若设为 unlimited 或具体数值（如 2G）：仅表示“允许最大写入这么多”，不指定路径、不保证生成、不绕过内核限制。

示例配置（nginx.conf）：

worker_rlimit_core 2G;
working_directory /var/tmp;  # 注意：此指令仅影响 worker 进程的工作目录，对 core 路径无直接作用（见下文）

⚠️ 注意：working_directory 不是 core 存放路径！它只在 kernel.core_pattern 设为相对路径（如 core.%p）时，作为 fallback 目录使用；若 core_pattern 是绝对路径（推荐），则完全忽略该目录。

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

二、Core 文件物理路径由谁决定？怎么指定？

真正控制“写到哪、叫什么名、能不能写进去”的，只有两个系统级配置：

• ulimit -c（进程级权限）
  必须非零（推荐 unlimited），否则 kernel 直接拒绝 dump。
  worker_rlimit_core 只是让 Nginx 帮你设这个值，但：

  • 它不覆盖 systemd 服务的独立限制（如 LimitCORE=infinity）；
  • 若 Nginx 由 systemd 管理，必须同时在 .service 文件中配 LimitCORE=infinity，否则 worker_rlimit_core 会被 systemd 覆盖。

• kernel.core_pattern（内核级路径与命名）
  这才是物理路径的唯一权威来源。例如：

  echo '/var/crash/core.nginx.%e.%p.%t' | sudo tee /proc/sys/kernel/core_pattern

  此时所有崩溃的 Nginx worker（只要 ulimit -c 允许）都会把 core 写入 /var/crash/，文件名含名称、PID、时间戳。
  ✅ 推荐做法：用绝对路径 + 1777 权限目录，避免依赖工作目录权限问题。

三、Nginx 场景下的完整启用步骤（缺一不可）

1. 确保 systemd 服务不限制 core（若用 systemd 启动 Nginx）
   编辑 /etc/systemd/system/nginx.service，在 [Service] 下添加：

   LimitCORE=infinity

2. 在 nginx.conf 中启用 rlimit（可选，但建议显式设）

   worker_rlimit_core 2G;
   working_directory /var/tmp;  # 配合 core_pattern 相对路径时才起作用

3. 配置内核 core_pattern 到可靠路径

   sudo mkdir -p /var/crash
   sudo chmod 1777 /var/crash
   echo '/var/crash/core.nginx.%e.%p.%t' | sudo tee /proc/sys/kernel/core_pattern
   # 永久生效：写入 /etc/sysctl.conf 并执行 sysctl -p

4. 验证是否就绪

   # 检查 worker 进程的 ulimit
   ps aux | grep nginx | grep -v grep | head -1 | awk '{print $2}' | xargs -I{} cat /proc/{}/limits | grep core
   
   # 查看当前 core_pattern
   cat /proc/sys/kernel/core_pattern
   
   # 手动触发测试（在 worker 进程 PID 上发 SIGSEGV）
   kill -SEGV $(pgrep -f "nginx: worker")

Nginx worker 崩溃后，只要上述四步全满足，core 文件就会按 core_pattern 指定的物理路径生成，而非“靠 worker_rlimit_core 记录路径”。
它不记录路径，只传递大小权限；路径归属内核，权限归属 systemd 和 ulimit，落地成败取决于目录权限与磁盘空间。