当前位置：首页 > 文章列表 > 文章 > linux > Linux coredumpctl 如何保留崩溃现场：存储策略、权限与回溯检查

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

来源：17golang原创 2026-08-24 22:40:09 0浏览收藏

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

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

要点速览

coredumpctl list 先判断崩溃记录是否存在，present 才表示现场仍可取用。
/proc/sys/kernel/core_pattern 决定内核把崩溃交给谁，不能只看应用目录里有没有 core 文件。
保留策略要同时关注存储位置、单个 core 大小上限和磁盘空间，权限不足时不要直接放宽到全员可读。
导出后用与服务二进制匹配的调试符号加载 gdb，回溯才有函数名和行号可读。

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

第一次遇到服务崩溃，最容易走错的是直接执行 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”。

Linux coredumpctl 从崩溃时间、PID 和信号到 present 状态的现场证据链

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

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

现象	优先核对	不要误判为
列表没有记录	`core_pattern`、资源限制、收集链路	应用一定没有崩溃
记录存在但状态不是 present	存储策略、清理规则、磁盘空间	现场仍可直接导出
回溯只有地址	二进制和调试符号版本	崩溃位置不可分析

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

确认有记录后，再看保留规则。常见配置文件是 /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 是否来自同一次发布；然后安装或挂载对应版本的调试符号，不要把另一版本的符号目录硬套上去。

Linux coredumpctl dump 导出 core 后由 gdb 加载二进制并检查调用回溯

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

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

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

常见问题

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

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

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

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

为什么 gdb 看不到函数名？

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

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

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

总结

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