Linux systemd 服务崩溃后怎么保留现场：core 记录、信号与调试符号核对

Linux 上的 systemd 服务突然异常退出时，最有价值的线索不一定藏在日志末尾，很可能是一份由 systemd-coredump 自动留存的崩溃现场文件。排查这类问题可以先用 coredumpctl list 确认系统到底有没有生成对应的 core 记录，再用 info 核对崩溃信号、进程上下文和对应可执行文件信息，最后再判断要不要导出原始 core 文件或是进入调试器分析。

先确认服务退出是否留下了 core 记录

假设出问题的服务名称是 image-worker.service，直接筛选查看最近的相关崩溃记录：

coredumpctl list
coredumpctl list image-worker.service

重点核对崩溃发生时间、PID、终止信号、可执行文件路径和关联的服务标识。如果筛选不到对应结果，不能直接下结论说程序没有触发崩溃：它可能是被正常运维操作停止、被系统 OOM killer 主动终止，或是 systemd-coredump 收集组件没正常接管这次崩溃。

用 info 指令锁定单次崩溃现场元数据

coredumpctl info 24831
coredumpctl info /opt/image-worker/bin/worker

info 会完整展示崩溃时间、触发信号、启动命令行、运行用户、内核版本和程序文件哈希等核心元数据。先记下 Signal、Command Line 和程序文件标识，再和对应服务的发布版本做比对；如果 core 记录对应的二进制文件之后被覆盖替换，后续做地址解析的时候结果大概率会完全失真。

区分 SIGSEGV、SIGABRT 和外部主动终止的场景

SIGSEGV 一般对应非法内存访问类的问题，SIGABRT 大多来自程序内部断言失败或是代码主动调用 abort 触发；如果崩溃是上层服务管理器主动下发停止信号导致的，就不能把它归为程序自身逻辑崩溃。

systemctl status image-worker.service --no-pager
journalctl -u image-worker.service -n 100 --no-pager

两边的时间线要完全对齐。coredump 记录里的信号能说明进程最后是以什么方式结束的，服务自身的运行日志能补上崩溃前一刻发生的业务上下文；只单看其中一边的信息，很容易把依赖超时、健康检查失败这类外部问题，和真正的内存访问错误搞混。

需要离线分析时，用 dump 导出保留原始证据

mkdir -p /var/tmp/image-worker-crash
coredumpctl dump 24831 --output=/var/tmp/image-worker-crash/core.24831
sha256sum /var/tmp/image-worker-crash/core.24831

导出之前先确认磁盘剩余空间和目标文件的访问权限。core 文件里可能留存着请求明文数据、令牌片段或是内存里缓存的用户敏感信息，绝对不能随意上传到公开可访问的路径。导出后生成哈希值只用来确认后续分析用的就是同一份原始文件，不能用来证明程序问题已经修复。

进入调试器前，先完成二进制和符号的匹配校验

coredumpctl debug 24831

如果栈回溯输出全是陌生的十六进制地址，优先排查三个点：二进制是不是来自同一次发布包、文件有没有被 strip 剔除符号、对应版本的调试符号包有没有在本地部署成功。不要以为成功进入 gdb 就代表拿到了有效可分析的现场。

全局保留策略决定后续出问题还能不能复盘

grep -R '^[A-Za-z].*=' /etc/systemd/coredump.conf /etc/systemd/coredump.conf.d 2>/dev/null
df -h /var/lib/systemd/coredump /var/tmp

不同 Linux 发行版默认采用的存储路径、单文件大小上限和自动清理周期都不一样。生产环境不要为了多存几份 core 就直接关掉自动清理机制；更稳妥的方案是根据磁盘容量预算设置合理的上限值，给崩溃文件单独配置受控的访问权限，同时把对应发布版本的二进制、构建 ID 和调试符号包统一纳入制品库管理。

一份可以直接落地的崩溃复查清单

1. 用 systemctl status 记录异常服务的状态、退出时间和对应发布版本。
2. 用 coredumpctl list 服务名 筛选匹配对应时间点的崩溃记录。
3. 用 coredumpctl info PID 固定崩溃信号、启动命令行、运行用户和可执行文件信息。
4. 把 coredump 生成的时间点和 journalctl -u 的前后运行日志做时间线对齐。
5. 需要离线分析时导出完整 core 文件，记录文件哈希并配置受限访问权限。
6. 确认二进制、构建 ID 和调试符号三者完全匹配后，再进入 coredumpctl debug 做深度调试。

相关问题

为什么服务明明崩溃了却查不到 coredumpctl 记录？

可能是进程被正常终止、systemd-coredump 收集服务没运行、旧的 core 记录已经被自动清理，或是系统全局配置限制了 core 文件生成。先查服务最终退出信号和 systemd-coredump 组件的运行状态，再核对当前发行版的 core 大小限制和存储路径配置。

coredumpctl info 能替代 gdb 调试吗？

不能。info 适合快速核验现场元数据和已经自动生成的浅层次回溯；想要查看完整栈帧、局部变量和多线程状态时，还是要使用匹配好符号的调试器做深度分析。

总结

处理 systemd 服务崩溃问题时，操作顺序比会多少命令更重要：先找到对应崩溃记录，再确认信号类型和版本信息，接着对齐运行日志和核对保留策略，最后再启动调试。这样既可以减少很多无效的 gdb 操作，也能避免等到 core 已经被清理、二进制已经被替换之后才发现手里的证据根本没法用。