coredumpctl 怎样按 PID 导出转储

已知崩溃 PID 时，可以使用 coredumpctl --output=目标文件 dump PID 导出已保存的 core。先用 list 或 info 确认匹配的是目标崩溃；同一 PID 可能对应多条历史记录，dump 取的是符合条件的最后一份转储，不是当前同号进程的内存。

官方地址：https://www.freedesktop.org/software/systemd/man/latest/coredumpctl.html。采集与存储说明：https://www.freedesktop.org/software/systemd/man/latest/systemd-coredump.html。以下命令使用虚构 PID 和演示路径，未在本机执行，也没有制造真实崩溃。

问题：知道崩溃 PID，怎样拿到 core 文件

问题中的 PID 应来自那次崩溃记录，例如事故日志写明 worker 的崩溃进程号是 24680。这里假定主机已经由 systemd-coredump 保存相关数据。coredumpctl 的职责是检索已有记录和转储，不能凭一个数字从过去重新生成已经丢失的内存内容。

因此“导出失败”要拆成两类：选错记录，或者记录存在但 core 数据不可访问。反复更换输出扩展名不会解决后一类问题。

结论：dump 配合明确的输出文件

# 24680 只是示例，应替换为崩溃进程当时的 PID。
sudo coredumpctl --output=./worker-24680.core dump 24680

dump 是取出转储数据的动作，--output 指定写入位置；文件名由你决定，.core 只是便于辨认。sudo 用于有授权且需要读取系统记录的场景，当前用户有权限时可以直接执行。输出文件的目录应由你控制，并预留足够空间。

不指定输出文件时，dump 默认把二进制转储写到标准输出。这与 info 的可读说明不同，不适合当作普通终端文本查看，也不应混进应用日志。

误区：PID 不是长期唯一标识

PID 会重用，跨重启或长期运行的机器上，单靠进程号并不能长期标识一次事故。先看匹配条目的时间和可执行路径，必要时加入时间窗口与其他 journal 字段。不要把“取最新匹配项”误解成“取我心里那次崩溃”。

# 先查看这个崩溃 PID 的匹配条目，不主动制造进程崩溃。
sudo coredumpctl --no-pager list 24680
# 查看详细元数据，确认时间、程序路径与所属启动批次。
sudo coredumpctl --no-pager info 24680

info 中的程序路径、时间和 Boot ID 有助于确认上下文。对于脚本程序，可执行文件可能显示为解释器，因此仅靠 EXE 也未必足够；筛选范围仍应贴合那次记录。

正确做法：筛选同一次崩溃再导出

下面使用时间窗口、COREDUMP_PID 和 COREDUMP_EXE 缩小范围。先列出范围内的条目，确认只剩目标事故；如果仍有多条，继续细化条件。不要只给 list 加条件，真正 dump 时又退回只传 PID。

# 日期、时间窗口、PID 和程序路径均需替换为实际崩溃信息。
sudo coredumpctl --no-pager --since="2026-10-24 09:10:00" --until="2026-10-24 09:20:00" list COREDUMP_PID=24680 COREDUMP_EXE=/opt/demo/bin/worker
# 使用完全相同的筛选条件读取元数据。
sudo coredumpctl --no-pager --since="2026-10-24 09:10:00" --until="2026-10-24 09:20:00" info COREDUMP_PID=24680 COREDUMP_EXE=/opt/demo/bin/worker
# 确认目标后，显式输出到文件，避免二进制内容进入终端。
sudo coredumpctl --since="2026-10-24 09:10:00" --until="2026-10-24 09:20:00" --output=./worker-24680-incident.core dump COREDUMP_PID=24680 COREDUMP_EXE=/opt/demo/bin/worker

时间字符串按主机工具的时间解析规则解释，请使用与事故记录一致的时区背景。程序路径必须取自真实记录，不要照抄 /opt/demo/bin/worker。这里列出的命令只负责示范参数组合，没有伪造匹配条目或导出成功输出。

边界情况：有日志但转储不可取

journal 元数据与外部 core 文件的清理相互独立，所以 list 仍有一行，并不保证转储字节还在。导出工具无法补回已删除或未保存的数据；需要保留的事故材料，应在现有运维流程允许的保留期内处理。

若完全没有条目，应回到主机的采集配置与记录范围查原因，而不是凭 PID 盲目重试。本文只讨论已有转储的检索和导出，不展开更改内核采集配置或主动触发崩溃。

延伸问题与导出记录

# 导出后，配套保存同一筛选范围的元数据说明。
sudo coredumpctl --no-pager --since="2026-10-24 09:10:00" --until="2026-10-24 09:20:00" info COREDUMP_PID=24680 COREDUMP_EXE=/opt/demo/bin/worker > ./worker-24680-incident.info.txt
# 查看文件属性；sudo 导出的所有者与读权限需按调试安排管理。
ls -lh ./worker-24680-incident.core ./worker-24680-incident.info.txt

与 core 一起保留匹配元数据、程序构建版本和相应调试符号，能让后续分析更容易定位正确二进制。转储可能含进程内存中的业务数据，交接时按团队的事故资料权限管理即可，不要把它当作可随意公开的普通示例文件。

dump 24680 是导出当前进程吗？

不是，它在已有崩溃记录中匹配这个崩溃 PID。要获取一个仍在运行进程的状态属于另一个操作，不能混用这个含义。

info 保存成文本等于 core 吗？

不等于。info 是元数据与可用说明，dump 才是本题需要的二进制转储。两者应该使用不同文件名保存，避免交付时混淆。

想直接进入调试器，还需要导出吗？

coredumpctl 另有 debug 动作。是否先导出取决于调试位置和事故材料交接需求；本题强调拿到独立文件，因此采用 dump。

权限提升后还是 missing 怎么办？

missing 表达的是对应外部数据已不在，权限提升不能恢复被清理的文件。应查看是否另有已授权的事故备份，并避免把不同记录的 core 混作目标材料。