coredumpctl 怎么把指定崩溃导出给调试器

服务器上连续发生多次崩溃时，直接执行 coredumpctl dump 很容易拿到“最后一次”而不是事故对应的那一次。更稳妥的做法是先用 PID、可执行文件路径或 journal 匹配条件缩小范围，再用 info 核对身份，最后通过 dump --output 导出；导出后的文件再和对应的可执行文件一起交给 gdb。

先用明确条件锁定目标崩溃

coredumpctl 的匹配参数可以放在命令后面：整数会按 PID 匹配，带斜杠的路径会按 EXE 匹配，不带斜杠的名称可按 COMM 匹配。先列出记录，再决定哪个条目值得导出。

# 用 PID 精确筛选，并关闭分页，便于保存结果
coredumpctl --no-pager list 24817

# 也可以按程序的绝对路径筛选
coredumpctl --no-pager list /usr/local/bin/order-worker

重点看 COREFILE：present 表示当前用户可访问外部 core，journal 表示内容存于日志，missing 或 error 则不适合直接交给调试器。只剩一条候选时，再进入详细核对。

用 info 核对 PID、命令行和存储状态

不要把“列表里看到了记录”当成“文件一定能读”。使用同一个匹配条件执行 info，核对时间戳、Signal、Command Line、Executable 和 Storage。下面的 PID 只是示例，实际值替换成列表中的目标 PID。

# 查看这一次崩溃的详细元数据，不把其他记录混进来
coredumpctl --no-pager info 24817

# 只取最新的一条记录时，也要保留程序路径作为边界
coredumpctl --no-pager -1 info /usr/local/bin/order-worker

如果当前用户看不到系统服务产生的记录，应先确认日志和 core 的读取权限；提升权限只能解决访问边界，不能修复已经被清理或从未保存的 core。

用 dump --output 导出，再交给调试器

dump 不指定输出文件时会把 core 写到标准输出。为了得到稳定的文件，使用 -o 或 --output，并沿用已经核对过的匹配条件。

# 导出指定 PID 对应的 core；目标目录需提前准备并具备写权限
install -d -m 0700 /tmp/order-worker-debug
coredumpctl --no-pager -o /tmp/order-worker-debug/core.24817 dump 24817

# 将目标程序和导出的 core 一起交给 gdb
gdb /usr/local/bin/order-worker /tmp/order-worker-debug/core.24817

文件存在且命令退出码为 0，只能说明导出动作完成；调试器能否还原有效栈，还取决于可执行文件版本、共享库和调试符号是否对应。若只想对最近一条匹配记录直接启动调试器，可使用 coredumpctl debug 24817；默认调试器是 gdb，也可以通过 --debugger= 或 SYSTEMD_DEBUGGER 改变。

参数边界与排查清单

相关问题

可以直接用 coredumpctl debug 代替 dump 吗？

可以，但它更适合临时检查；需要留档、交给同事或重复分析时，先用 dump --output 保存明确文件更稳妥。

为什么 list 能看到记录，dump 却失败？

日志元数据和 core 文件的保留策略并不完全相同，记录仍在不代表对应 core 一定可读；同时检查 COREFILE 和权限。

只有一个程序多次崩溃时怎么避免选错？

不要只按 COMM 匹配，优先使用 PID；若 PID 已知，再用 info 核对时间戳和命令行。