Linux core dump 怎么安全落盘：systemd-coredump 的大小、权限与保留策略

线上服务偶发崩溃时，core dump 能把“进程为什么死了”留成可复查的现场，但默认保存策略未必适合一台长期运行的 Linux 主机：文件可能占满专用目录，普通运维账号也可能看不到内容。用 systemd-coredump 时，建议把“是否保存、单个文件多大、目录最多占多少、多久清理”分开核对。

最稳妥的做法是先确认当前生效值，再用 drop-in 设置边界，最后用一次受控崩溃检查 journal 记录、core 文件权限和清理行为；不要只改一个总开关就认为策略已经完整。

先把 core dump 的两条保存路径分开

systemd-coredump 会把崩溃摘要写入 systemd journal，并可能把进程内存镜像保存为外部文件。常见外部目录是 /var/lib/systemd/coredump，但“journal 里还能列出记录”和“对应 core 文件仍然存在”不是同一件事。

先看当前配置与目录，而不是直接覆盖文件：

coredumpctl info --no-pager
ls -ld /var/lib/systemd/coredump
ls -l /etc/systemd/coredump.conf /etc/systemd/coredump.conf.d/ 2>/dev/null

如果 coredumpctl list 能看到记录，但状态是 COREFILE=missing，说明元数据还在，外部 core 已经被清理或不可访问。这个状态不能直接推断为“收集器没有工作”。

用 drop-in 同时约束大小与目录占用

建议把本机策略写进 /etc/systemd/coredump.conf.d/50-local-limits.conf，便于审计和回退：

[Coredump]
Storage=external
ProcessSizeMax=512M
ExternalSizeMax=256M
MaxUse=5G
KeepFree=10G

这里有四个不同边界：ProcessSizeMax= 限制处理的进程映像，ExternalSizeMax= 限制单个外部文件，MaxUse= 限制 coredump 目录总量，KeepFree= 保留文件系统可用空间。单独设置 Storage=external 不会替你限制磁盘增长。

写完后用发行版提供的查询方式确认配置文件被读到；不同 systemd 版本的输出细节会不同，至少要确认文件语法无误、目标目录可写。配置在下一次 core dump 到来时生效，不需要为此重启整台主机。

一次受控验证：看见什么才算生效

验证应在测试机或可回滚的副本上做。先记录空间与最近记录，再触发一个明确的测试进程崩溃；生产环境不要为了验证随意杀掉业务进程。

df -h /var/lib/systemd/coredump
coredumpctl list --no-pager -n 5
coredumpctl info --no-pager -1

成功状态至少包括：journal 中出现新的崩溃条目，条目里的进程、信号和时间符合测试进程；若策略允许外部保存，COREFILE 应显示 present 或其他与限制相符的状态；目录占用没有越过 MaxUse=，文件系统可用空间仍高于 KeepFree=。

三个容易混在一起的回退动作

只停止外部保存

如果现场只需要 journal 摘要，可把 Storage=none 与 ProcessSizeMax=0 一起评估。保留旧文件不会自动发生，清理前先按保留要求导出需要的证据。

只降低目录压力

优先调小 MaxUse= 或增大 KeepFree=，不要误把 ProcessSizeMax= 当作历史文件清理开关。core 文件目录和 journal 有各自的生命周期。

需要调试时再导出

coredumpctl dump 可以把匹配的 core 导出到指定文件；导出文件应进入受限目录，并在排障完成后按团队保留规则删除。权限不足时不要用放宽整个目录权限来“临时解决”。

常见问题

为什么 journal 有记录但找不到 core 文件？

外部文件可能已经被清理，也可能当前账号没有读取权限。先看 COREFILE 状态和目录权限，再判断收集是否失败。

改完配置后为什么旧 core 没变化？

配置主要影响后续收到的 core dump；已有文件的大小和权限不会被历史性重写。

MaxUse 和 KeepFree 是否二选一？

不是。前者限制目录使用量，后者给所在文件系统留安全余量，实际清理会受到两者共同影响。

把验证结果留在发布检查单里

最终记录当前配置文件路径、coredumpctl list 的测试条目、COREFILE 状态、core 目录占用和文件系统剩余空间。这样下次升级 systemd 或调整日志保留周期时，能分辨是收集器、权限、目录清理还是 journal 生命周期发生了变化。