core_pattern配置需满足绝对路径、父目录手动创建、权限1777、无noexec/nodev挂载选项；命名推荐/var/crash/core.%e.%p.%t；systemd服务须设limitcore=infinity；setuid程序需suid_dumpable=2；务必手动验证落地。
core_pattern 必须设为绝对路径且父目录得手动创建
内核写 core 文件时不会自动建目录，哪怕 /var/crash 少一级子目录，core 就会静默失败。不是报错，是根本没文件——你查日志也找不到线索。
执行这三步：
sudo mkdir -p /var/crash-
sudo chmod 1777 /var/crash（注意：必须是1777，777不行，1755也不行） - 确认父目录所在文件系统没挂载选项
noexec或nodev，否则部分发行版会拦截写入
命名规则用 %e.%p.%t 最实用，别碰 %E 或 %h
%E（全路径）看似方便，但实际在 systemd 服务或容器中常被截断或含非法字符；%h 在 Kubernetes Pod 或 Docker 容器里通常是短 ID，无区分度。生产环境推荐：
-
/var/crash/core.%e.%p.%t—— 简洁、可排序、不含空格（前提是你的可执行名本身没空格） - 避免
%s单独使用：信号编号如11不直观，不如后续用file或gdb查 - 别写
~/crash或$HOME/crash：core_pattern不解析 shell 变量，~会被当字面路径，可能写进根目录
systemd 服务必须单独加 LimitCORE=infinity
你在终端里跑 ulimit -c unlimited 对 systemd 启动的服务完全无效。哪怕 core_pattern 和目录权限都对，服务崩溃照样没 core。
编辑对应 unit 文件，例如 /etc/systemd/system/myapp.service：
- 在
[Service]段下加一行：LimitCORE=infinity（不能写unlimited） - 重载并重启：
sudo systemctl daemon-reload && sudo systemctl restart myapp - 验证生效：
systemctl show myapp | grep LimitCORE，输出应为LimitCORE=18446744073709551615
setuid 程序要额外开 suid_dumpable=2
像 sudo、passwd 这类程序即使其他配置全对，也会静默跳过生成 core。这是内核默认安全策略，不是 bug。
- 临时启用：
echo 2 | sudo tee /proc/sys/kernel/suid_dumpable - 永久生效：写入
/etc/sysctl.conf的fs.suid_dumpable=2，再执行sudo sysctl -p - 这个值不继承、不跨 reboot 生效，漏掉就等于对特权进程“盲调”
最容易被忽略的是：core_pattern 配置后不验证是否真能落地。建议用 kill -SEGV $$ 在目标环境（尤其是 systemd service 下）手动触发一次，再立刻检查 /var/crash/ 是否出现新文件——别等真崩溃才试。
