如果你发现直接修改/proc/sys/kernel/core_pattern后仍然没有生效，通常问题并不在“有没有改成功”，而是几个关键前置条件没有同时满足：首先，这里的路径必须填写为绝对路径；其次，父目录需要提前创建，并且权限必须设置为1777；如果目标程序是由systemd管理的服务，还需要额外配置LimitCORE=infinity；此外，fs.suid_dumpable=2也必须启用，否则同样会导致内核转储文件无法正常生成。
直接修改 /proc/sys/kernel/core_pattern 后不生效？多数情况下不是命令写错，而是内核没有权限把 core dump 写入你指定的目录，或者目标目录本身就不存在。
core_pattern 路径必须使用绝对路径，且父目录必须提前存在并设置正确权限
内核只负责把转储数据写入指定位置，并不会自动帮你创建目录。比如你希望将 core dump 保存到 /var/crash/core.%e.%p.%t，但如果 /var/crash 目录不存在，那么程序崩溃时生成的 core 文件就会被静默丢弃。
- 先手动创建目录：
sudo mkdir -p /var/crash - 目录权限必须设置为
1777（sticky + world-writable）：sudo chmod 1777 /var/crash—— 少任何一个7，或者误设成755，都可能导致无法写入 core_pattern中不能使用~、$HOME或相对路径（例如../core），内核只识别标准绝对路径
systemd 服务必须单独设置 LimitCORE=infinity
你在终端中执行 ulimit -c unlimited 并不能解决systemd服务的core dump问题——因为由systemd启动的服务不会继承当前shell的这个限制。即使 /proc/sys/kernel/core_pattern 配置正确、全局 ulimit 也没问题，只要服务本身没有放开限制，程序崩溃后依旧不会生成 core 文件。
- 编辑对应的 unit 文件，例如
/etc/systemd/system/myapp.service - 在
[Service]段中添加一行：LimitCORE=infinity（注意这里必须是infinity，不是unlimited） - 重载配置并重启服务：
sudo systemctl daemon-reload && sudo systemctl restart myapp - 验证是否已生效：
systemctl show myapp | grep LimitCORE，正常输出应为LimitCORE=18446744073709551615
想让配置永久生效，需要修改两个关键配置项
临时修改 /proc/sys/kernel/core_pattern 只在当前运行周期内有效，系统重启后就会失效。对于CentOS 7等生产环境服务器，建议将配置写入持久化文件中。
- 写入
/etc/sysctl.conf：echo "kernel.core_pattern=/var/crash/core.%e.%p.%t" | sudo tee -a /etc/sysctl.conf - 立即刷新配置：
sudo sysctl -p - 同时确认
fs.suid_dumpable = 2已开启（尤其是涉及 setuid 程序时），否则这类进程默认不会生成 core dump
常见问题现象与排查验证方法
修改完成后还是没有生成 core 文件？先不要反复重试，建议按下面几个关键点逐项排查：
- 使用
cat /proc/sys/kernel/core_pattern确认当前值已经更新，并检查是否包含空格、非法字符或错误路径 - 运行一个必然崩溃的测试程序：
kill -SEGV $$（在当前 shell 中触发段错误），观察是否真的生成了 core 文件 - 查看
dmesg | tail输出，如果出现coredump: failed to write或permission denied，通常就是目录权限或保存路径配置有问题 - 确认进程当前工作目录不会影响路径解析 —— 当
core_pattern使用绝对路径时，它与进程的 cwd 完全无关
最容易被忽视的几点是：目录已经存在，并不等于权限设置正确；配置内容写对了，也不代表systemd服务已经读取并应用；你在shell里执行 ulimit -c unlimited 生效，也不意味着服务进程同样生效。想让CentOS 7内核转储文件路径修改真正生效，这几个环节缺一不可。
