linux中core dump默认存于进程工作目录，但实际由kernel.core_pattern控制：绝对路径直接写入，相对路径才回退到工作目录；推荐设绝对路径如/var/crash/core.%e.%p并确保目录可写。
Linux 系统默认将 Core Dump 文件生成在进程当前工作目录（即 working_directory），但该路径不是通过某个配置项叫 working_directory 来指定的——这是一个常见误解。实际上，Core Dump 的存放位置由内核参数 kernel.core_pattern 控制，而“进程的工作目录”仅在 core_pattern 中使用 %e、%p 等模板且未指定绝对路径时，才作为 fallback 路径起作用。
理解 core_pattern 与实际写入路径的关系
当进程崩溃时，内核根据 /proc/sys/kernel/core_pattern 的值决定如何命名和存放 core 文件：
- 若
core_pattern是**绝对路径**（如/var/crash/core.%e.%p），core 文件直接写入该路径，与进程当前工作目录无关； - 若
core_pattern是**相对路径**（如core.%e.%p或./core.%p），则 core 文件会尝试写入**进程当时的 working directory**； - 若进程工作目录不可写（如权限不足、磁盘满、挂载为 noexec/nodev），即使 pattern 是相对路径，core dump 也会失败（不生成文件）。
推荐做法：用绝对路径 + core_pattern 统一管理
避免依赖进程工作目录的不确定性，应显式设置绝对路径：
- 临时生效（重启后失效）：
echo '/var/crash/core.%e.%p' | sudo tee /proc/sys/kernel/core_pattern - 永久生效：编辑
/etc/sysctl.conf，添加一行：kernel.core_pattern = /var/crash/core.%e.%p
然后运行sudo sysctl -p - 确保目标目录存在且可写：
sudo mkdir -p /var/crash && sudo chmod 1777 /var/crash（1777 允许所有用户写入但不能删他人文件）
如果必须基于 working directory 控制（不推荐）
仅适用于调试场景或容器中无法修改 sysctl 的情况：
- 确保进程启动前
cd到期望目录，再执行程序； - 设置
core_pattern为相对形式，例如：echo 'core.%p' | sudo tee /proc/sys/kernel/core_pattern - 验证当前工作目录是否可写：
touch ./test_core_write && rm test_core_write - 注意：systemd 服务默认工作目录是
/，若未显式设置WorkingDirectory=，core 会尝试写入根目录（通常权限拒绝）。
验证与调试技巧
确认配置是否生效并定位问题：
- 查看当前 pattern：
cat /proc/sys/kernel/core_pattern - 检查 ulimit 是否允许生成 core：
ulimit -c（非 0 才启用；临时开启：ulimit -c unlimited） - 手动触发 core（测试用）：
kill -SEGV $$（向当前 shell 发送段错误） - 查看系统日志是否有拒绝记录：
dmesg | tail -10 | grep -i "core\|dump"
