Linux coredumpctl 找不到崩溃文件时怎么查存储策略

如果 coredumpctl list 能看到崩溃记录，却找不到可以交给 GDB 的文件，先不要急着改 kernel.core_pattern。这通常不是“崩溃没有发生”，而是 journal 里的元数据、外部 core 文件、文件保留时间和当前用户权限处在不同状态。

先看 COREFILE：present 表示当前用户能访问 core，missing 表示记录还在但外部文件已被删除，error 多半是权限不足，none 则是没有保存 core。只有确认这一层，后面的配置调整才不会跑偏。

先分清 journal 记录和 core 文件是否还在

先列出最近的记录，不要只盯着进程名：

# 只看最近记录，避免分页器遮住 COREFILE 列
coredumpctl list --reverse -n 20 --no-pager

# 用 PID 查看这一条记录的存储路径、大小和信号
coredumpctl info 12345 --no-pager

present、journal 和 truncated 的含义不同：前两者仍有可读取内容，truncated 说明受大小限制而不完整；missing 通常对应 COREDUMP_FILENAME 指向的文件已被清理。官方文档还特别说明，journal 条目的保留与外部 core 文件的删除彼此独立，因此“记录还在”不能证明“文件也还在”。

内核入口和 systemd-coredump 是否接上了

如果连新崩溃都没有出现在列表中，再检查采集入口。systemd-coredump 依赖 kernel.core_pattern 把 core 处理交给它；由 systemd 管理的服务还可能通过 LimitCORE= 把进程的 core 大小软限制设为零。

# 查看内核当前的 core 处理入口
sysctl kernel.core_pattern

# 确认 socket 激活单元是否存在并在监听
systemctl status systemd-coredump.socket --no-pager

# 查看服务的 core 限制，注意只对该 unit 生效
systemctl show my-worker.service -p LimitCORE

这里有一个容易误判的边界：ulimit -c 只代表当前 shell 或进程的资源限制，不会替代 systemd unit 的 LimitCORE=。如果应用由容器、用户服务或其他 supervisor 启动，应该沿着实际启动链查看限制，而不是只在登录 shell 里执行一次命令。

Storage、大小上限和清理策略要分开看

使用配置合并结果比直接猜某个文件更可靠：

# 展开主配置和 drop-in，确认最后生效的 coredump 设置
systemd-analyze cat-config systemd/coredump.conf

# 查看外部目录是否有文件，以及文件的时间和属主
sudo ls -lah --time-style=long-iso /var/lib/systemd/coredump

# 查看 systemd-coredump 自己记录的处理错误
sudo journalctl -u systemd-coredump --since "2 hours ago" --no-pager

生产环境通常先用 drop-in 明确策略，而不是直接改发行版提供的文件。例如要保留外部文件，同时控制单个文件大小，可以写入 /etc/systemd/coredump.conf.d/50-local.conf：

[Coredump]
# 选择外部文件保存，便于后续 coredumpctl dump 或 gdb 使用
Storage=external
# 只限制单个 core，避免一次崩溃占满磁盘
ExternalSizeMax=2G

如果站点有敏感内存数据，不能为了“方便排障”盲目把上限调大。先确定采集范围、访问权限和保留周期，再选择 journal 或外部文件。

修复后用一次新的崩溃做回归

配置改完后，重新加载 systemd 并确认合并结果；不要拿一条已经被清理的旧记录证明修复成功：

# 让新的 unit 配置在后续启动时生效
sudo systemctl daemon-reload

# 再次确认最终配置，避免 drop-in 拼写或优先级错误
systemd-analyze cat-config systemd/coredump.conf

# 新事件发生后按 PID 查看，期望 COREFILE 为 present 或 journal
sudo coredumpctl list --reverse -n 1 --no-pager
sudo coredumpctl info 12345 --no-pager

如果普通用户看到 error，但 sudo coredumpctl info PID 显示 present，优先处理 journal 访问权限和运维角色，而不是重新配置存储。若状态是 missing，再回到外部目录、tmpfiles 清理和磁盘空间检查。

常见问题

为什么 coredumpctl 有记录，目录里却没有文件？

journal 元数据和外部 core 文件独立保留，文件可能被 tmpfiles 清理，也可能从未按当前 Storage 策略落盘。

把 Storage 改成 external 后旧记录会恢复吗？

不会。它只影响后续收到的崩溃；旧记录已经被删除的 core 无法凭配置找回。

看到 error 是否一定是文件损坏？

不一定。先用有权限的账户复查；官方定义里 error 很可能是当前用户无权访问。

排查顺序可以固定为：先读 COREFILE，再查 kernel.core_pattern 和 unit 限制，最后核对 Storage=、大小上限、磁盘与 tmpfiles。这样每一步都对应一个可证伪的原因。