Linux coredumpctl 如何保留崩溃现场：存储策略、权限与回溯检查

线上服务突然退出时，真正难的是“进程没了，证据也没了”。如果机器使用了 systemd 的崩溃收集链路，先别急着翻某个目录：用 coredumpctl list 确认记录是否存在，再核对保存策略、文件权限和调试符号，最后把现场导出给 gdb。这样排查出来的结论，才不会停留在一行退出日志上。

保留崩溃现场的关键不是盲目打开 core 文件，而是依次确认“是否记录、是否保留、能否读取、能否回溯”四件事。

先确认崩溃现场有没有被记录

第一次遇到服务崩溃，最容易走错的是直接执行 find / -name core。很多 Linux 主机把 core 交给崩溃收集程序压缩存储，应用工作目录里自然找不到一个叫 core 的普通文件。

coredumpctl list --no-legend | tail -5
cat /proc/sys/kernel/core_pattern
coredumpctl info --no-pager PID

列表中重点看时间、PID、触发信号、可执行文件和现场状态。通过管道交给收集程序时，core_pattern 通常以竖线开头；这时应以 coredumpctl 的记录为准。若列表为空，再去查进程的资源限制、收集服务状态和内核参数，不要先下结论说“程序没有生成 core”。

旧的做法为什么经常只剩一行退出日志

有些环境只设置了 ulimit -c unlimited，却没有确认服务启动时实际继承到的限制；有些环境记录到了 core，又因为磁盘配额或大小限制很快被清理。还有一种情况是文件还在，但服务使用了裁剪过的二进制，调试器只能显示地址，无法还原函数名。

用保留策略把现场留到真正需要的时候

确认有记录后，再看保留规则。常见配置文件是 /etc/systemd/coredump.conf 或其 drop-in 目录；重点不只是“是否保存”，还包括外部 core 的单个大小上限、处理大小上限以及磁盘空间能承受多久。

coredumpctl info --no-pager PID
grep -R --line-number -E '^(Storage|ProcessSizeMax|ExternalSizeMax|JournalSizeMax)=' \
  /etc/systemd/coredump.conf /etc/systemd/coredump.conf.d 2>/dev/null
df -h /var/lib/systemd/coredump /var/log 2>/dev/null

如果配置是 Storage=external，现场通常会落到专门的 core 目录；Storage=journal 则更依赖日志存储容量。配置调整前先记录当前值，并确认采集内容符合隐私和权限要求。core 可能包含令牌、请求参数或内存中的业务数据，不应因为排障方便就改成所有用户可读。

服务单元还要检查 LimitCORE

交互式 shell 里的限制不等于服务单元里的限制。对于由服务管理器启动的进程，检查单元实际生效的资源限制更可靠：

systemctl show demo-worker.service -p LimitCORE -p MainPID
systemctl cat demo-worker.service

若单元覆盖了资源限制，修改 shell 的 ulimit 不会改变服务。先用一个临时复现窗口验证，再把正式配置写进独立 drop-in，避免直接改发行版自带单元文件。

导出 core，再用匹配的符号做回溯

记录状态为 present 后，才进入导出阶段。建议把文件放到权限受控的临时目录，导出动作本身也留下 PID 和时间，方便后续把回溯结果对应回事故记录。

install -d -m 0700 /tmp/demo-worker-core
coredumpctl dump PID -o /tmp/demo-worker-core/core
file /tmp/demo-worker-core/core
gdb /opt/demo-worker/bin/demo-worker /tmp/demo-worker-core/core

进入 gdb 后，先执行 bt 看调用链，再用 thread apply all bt 观察其他线程。若输出只有十六进制地址，优先确认运行中的二进制和导出的 core 是否来自同一次发布；然后安装或挂载对应版本的调试符号，不要把另一版本的符号目录硬套上去。

用一轮复查把排障结果收口

修好问题或完成配置变更后，至少再验证一次“新崩溃能记录、现场能导出、权限没有被放宽”。可以把下面的清单放进值班手册：

• 用一条新的测试进程或受控复现确认 coredumpctl list 出现新记录。
• 确认记录的可执行文件路径、PID、信号和时间与本次复现一致。
• 执行 coredumpctl dump，检查导出文件大小和权限。
• 用匹配版本的二进制进入 gdb，确认 bt 至少能定位到函数层级。
• 复查磁盘容量、清理策略和 core 的访问权限。

常见问题

列表里有记录但不能 dump，怎么办？

先看现场状态和当前用户权限，再核对保留策略与磁盘空间。记录元数据还在，不代表完整 core 一定仍在。

没有安装 gdb 还能保留 core 吗？

可以。保留与回溯是两个阶段，先确保现场被可靠保存；需要分析时再在隔离的排障环境安装匹配工具。

为什么 gdb 看不到函数名？

最常见原因是二进制被剥离调试信息，或加载了不同发布版本的符号。把运行时二进制、core 和符号包按同一构建版本配对。

生产环境应该永久保存所有 core 吗？

通常不应该。根据磁盘预算、故障复现周期和数据敏感性设置容量与清理边界，必要时只保留受控样本并限制访问。

总结

一套可靠的 Linux 崩溃现场流程，顺序应当是先查记录入口，再查保留策略和权限，随后导出并用匹配符号回溯。coredumpctl list 解决“有没有”，info 和配置解决“还在不在、谁能读”，dump 与 gdb 解决“崩在哪”。把这四个判断固定下来，下一次服务退出时就不必从目录猜起。