core文件不写入指定目录的主因是内核无权写入：父目录必须预先创建且权限设为1777；systemd服务需单独配置limitcore=infinity；core_pattern以|开头时依赖systemd-coredump服务运行；setuid程序还需启用suid_dumpable=2。
core文件不写到你指定的目录？不是路径写错了，而是内核根本没权限往那里写，或者压根没创建父目录。
core_pattern 路径必须是绝对路径且父目录已存在
内核不会帮你创建目录树，只负责把数据写进去。如果 /var/crash 不存在，echo '/var/crash/core.%e.%p.%t' | sudo tee /proc/sys/kernel/core_pattern 看似成功，但程序崩溃时 core 文件会静默失败。
- 先手动创建目录：
sudo mkdir -p /var/crash - 必须设为 sticky + world-writable：
sudo chmod 1777 /var/crash（少一个7或不是1777都会拒绝写入） - 确认路径中不含 shell 变量或波浪号：
~/crash、$HOME/crash全部无效，只认纯绝对路径 - 相对路径如
../core会基于进程当前工作目录解析，极难预测，生产环境禁用
systemd 服务必须单独配置 LimitCORE
你在终端里跑 ulimit -c unlimited 没用——systemd 启动的服务完全不继承这个设置。哪怕 /proc/sys/kernel/core_pattern 和全局 ulimit 都对了，服务崩溃照样没 core。
- 编辑对应 unit 文件，比如
/etc/systemd/system/myapp.service - 在
[Service]段下加一行：LimitCORE=infinity（不能写unlimited，必须是infinity） - 重载并重启：
sudo systemctl daemon-reload && sudo systemctl restart myapp - 验证是否生效：
systemctl show myapp | grep LimitCORE，输出应为LimitCORE=18446744073709551615（即 infinity）
core_pattern 以 | 开头时，得确保接收端服务在运行
很多现代发行版（如 Ubuntu 22.04+、Fedora 36+）默认把 core_pattern 设成 |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e %p，走用户态处理。这时候生成失败，问题不在内核，而在管道另一端。
- 检查当前设置：
cat /proc/sys/kernel/core_pattern，开头是|就说明走管道 - 确认服务启用：
systemctl is-active systemd-coredump，如果不是active，运行sudo systemctl enable --now systemd-coredump - 查看日志：
journalctl -u systemd-coredump -n 50 --no-pager，常见错误是磁盘满、权限不足、或core_pipe_limit被设得太小 - 临时切回文件模式调试：
echo '/tmp/core.%e.%p.%t' | sudo tee /proc/sys/kernel/core_pattern
suid 程序崩溃不生成 core？检查 suid_dumpable
像 sudo、passwd 这类 setuid 程序，默认被内核禁止生成 core，即使 ulimit 和 core_pattern 全对也没用。这是安全策略，不是 bug。
- 查当前值：
cat /proc/sys/kernel/suid_dumpable，若为0则完全禁止 - 允许 dump（仅限调试环境）：
echo 2 | sudo tee /proc/sys/kernel/suid_dumpable（2表示“当进程明确设置了dumpable标志时才允许”，比1更安全） - 注意：该设置重启失效，如需持久化，写入
/etc/sysctl.conf并执行sudo sysctl -p - 验证方式：用
setuid程序触发崩溃（如sudo kill -SEGV $$），再看目标目录是否有文件
最容易被忽略的是：core_pattern 的路径权限必须是 1777，不是 755 也不是 777；systemd 服务的 LimitCORE 必须显式声明，且值只能是 infinity；还有，suid_dumpable 默认关着，连 root 运行的 setuid 程序都不会吐 core。
