ulimit -c unlimited 是 core dump 生效的前提开关，内核崩溃时若该值为0则直接跳过写入，后续所有配置无效；需结合 /proc/sys/kernel/core_pattern 路径设置、目录权限、suid_dumpable 等多层配置，并针对 systemd、容器、setuid 程序单独处理。

ulimit -c unlimited 为什么必须先做？

因为这是整个 core dump 生效的开关。内核在进程崩溃时会检查 ulimit -c 的值，如果为 0（Linux 默认值），直接跳过写入逻辑，连 /proc/sys/kernel/core_pattern 都不会读——后面所有配置全白搭。

• 临时生效：运行 ulimit -c unlimited 后，当前 shell 及其启动的所有子进程（比如你用 ./a.out 运行的程序）才可能生成 core
• 永久生效不能只靠 ~/.bashrc：systemd 服务、crontab、GUI 应用等不走用户 shell 初始化，需额外配 /etc/security/limits.conf 或服务单位文件里的 LimitCORE=infinity
• 验证是否真生效：执行 ulimit -c，输出必须是 unlimited，不是数字也不是 0

/proc/sys/kernel/core_pattern 怎么设才不丢文件？

默认 core 文件名没上下文，又默认写在当前工作目录（比如 /root、/tmp、甚至 /），极易被覆盖或权限拒绝。必须显式指定带标识的路径和命名模板。

• 推荐格式：/var/coredumps/core.%e.%p.%t ——%e 是程序名，%p 是 PID，%t 是 Unix 时间戳，三者组合基本杜绝重名
• 目标目录必须存在且可写：sudo mkdir -p /var/coredumps && sudo chmod 1777 /var/coredumps（注意不是 755，1777 才允许任意用户写入）
• 容器里要额外加 --ulimit core=-1 和 --privileged，否则即使 host 配好了，容器内仍受 cgroup 限制

为什么 setuid 程序死活不生成 core？

Linux 默认禁止对 root 权限程序生成 core，防止敏感内存泄露。这不是 bug，是安全策略，但调试时确实卡人。

• 关键参数是 /proc/sys/fs/suid_dumpable，值为 0（禁用）、1（仅 root 可读）、2（放开）
• 临时启用：echo 2 | sudo tee /proc/sys/fs/suid_dumpable
• 注意：该设置重启失效；若需持久化，得写进 /etc/sysctl.conf 并 sudo sysctl -p
• 有些发行版（如 RHEL/CentOS）还依赖 kernel.core_uses_pid=1，否则 %p 占位符不生效

怎么快速验证 core 真的能生成？

别等程序真崩——用 kill -SEGV $$ 主动触发当前 shell 进程段错误，它会立刻退出并按规则生成 core（前提是前面几步都对）。

• 执行前确认：cd /var/coredumps，再跑 kill -SEGV $$，然后 ls -lt core.* 看有没有新文件
• 如果没生成，优先查 ulimit -c 和目录权限，90% 的失败都在这两步
• 生成后别急着删：用 file core.xxx 确认是 ELF 核心转储，再用 gdb ./your_program core.xxx 进去 bt 看栈，才能确认是不是你想要的现场

最常被忽略的是：systemd 服务、Docker 容器、setuid 程序这三类场景，各自有独立的限制层，配完全局参数不等于它们就自动生效。