storage=、maxuse=、maxage=、compress=、zstdlevel=、processsizemax=、systemmaxuse=、runtimemaxuse= 等配置影响 core 文件生成与管理，但需重载 systemd 且仅对新进程生效。
coredump.conf 里哪些配置真会影响 core 文件生成
默认情况下，systemd-coredump 不会丢弃 core 文件，但很多人改了 /etc/systemd/coredump.conf 却发现没生效——根本原因是：修改后必须重载 systemd 配置，且部分选项只在新进程启动时起作用。
-
Storage=决定存哪：external（默认，存到/var/lib/systemd/coredump）、none（完全禁用）、journal（只记日志不存文件），设成none后旧进程已触发的 dump 不会消失，但新崩溃不会再落盘 -
MaxUse=和MaxAge=是清理开关，但它们**只对Storage=external生效**；设成journal或none后这两个参数就彻底被忽略 -
Compress=yes默认开启，压缩后文件名带.zst后缀，coredumpctl能自动解压，但手动用gdb打开前得先解压，否则报错No such file or Directory
手动清理 /var/lib/systemd/coredump 的安全方式
直接 rm -rf /var/lib/systemd/coredump 看似快，但可能破坏 systemd-coredump 的内部索引，导致 coredumpctl list 显示异常或漏掉条目。真正安全的做法是走 systemd 自带的清理路径。
- 用
systemd-tmpfiles --clean触发配置驱动的清理：它读取/usr/lib/tmpfiles.d/coredump.conf（或/etc/tmpfiles.d/coredump.conf），按MaxUse=/MaxAge=执行裁剪 - 临时清空所有：运行
coredumpctl --all --quiet --no-pager --no-legend --output= cat | xargs -r rm -f，但注意这绕过 tmpfiles 逻辑，适合紧急释放空间，不建议定期用 - 查大文件再删更稳妥：
find /var/lib/systemd/coredump -name "*.core*" -size +100M -ls | head -20，确认不是正在被coredumpctl debug持有锁的文件再删
coredumpctl list 显示不全或时间错乱的常见原因
coredumpctl list 依赖文件 mtime 和 coredump 文件头里的元数据，这两者不一致就会出现排序错乱、日期显示为 1970 年，甚至同一进程多次崩溃只显示一条。
- 系统时间跳变（如 NTP 校正、虚拟机休眠唤醒）会导致写入的 mtime 错乱，
coredumpctl优先信任文件 mtime，而非 core 头里的崩溃时间戳 - 使用
cp或rsync -a复制 core 文件会保留原 mtime，但新位置没有对应元数据，coredumpctl就无法关联到原始服务名和 PID - 如果
/var/lib/systemd/coredump所在分区是 noatime 挂载，不影响 list，但若误配为 relatime 或 strictatime，频繁访问会拖慢列表速度，实际影响不大
core 文件太大又不想关 Storage=external 怎么办
有些服务（比如 Java、Chromium）崩溃一次生成几个 GB 的 core，占满磁盘，但你又需要保留分析能力——这时靠压缩和过滤比直接禁用更实用。
- 启用
ZstdLevel=3（默认是 3，可设到 12，但 >6 后压缩率提升极小，CPU 开销明显上升） - 用
ProcessSizeMax=限制单个 core 文件大小，单位是字节，设成500M后超限的 dump 会被截断，coredumpctl debug仍能启动，但堆栈可能不完整 - 配合
SystemMaxUse=（全局）和RuntimeMaxUse=（仅 runtime 目录）双控，避免 /var/lib/systemd/coredump 占满根分区
真正难处理的是 core 文件被其他进程 mmap 锁住导致删不掉，这时候 lsof +D /var/lib/systemd/coredump 比猜更有用。另外，coredump.conf 的改动不会 retroactively 影响已存在的文件，这点很容易被忽略。