systemd-coredump压缩失败怎么解决

当 systemd-coredump 的核心转储文件未被压缩时，问题往往并非配置写错，而是深层机制被忽略：CoredumpCompress=yes 可能根本未生效（因配置未被正确加载或仅适用于用户级实例），ulimit -c 为 0 会直接阻止内核生成 core 文件，磁盘空间不足、zstd 缺失或被占用会导致静默失败，而 systemd-coredump 进程自身受 MemoryLimit 或 DefaultLimitAS 等内存限制约束时，甚至会让 zstd 压缩进程因 fork 失败或被 OOM 杀死——所有这些关键线索都藏在 journalctl -t systemd-coredump 的日志里，而非表面现象中。

systemd-coredump 压缩失败时先查 CoredumpCompress 是否真启用

很多用户看到 /var/lib/systemd/coredump/ 下的 core 文件没被压缩，就默认是 CoredumpCompress=yes 没生效，其实更常见的情况是：这个配置根本没被读到。systemd-coredump 的配置分两级——全局 /etc/systemd/coredump.conf 和用户级 /etc/systemd/coredump.conf.d/*.conf，但后者**仅当启用了 per-user instance 且 coredump 由 user manager 处理时才生效**；绝大多数服务崩溃走的是 system manager，只认前者。

验证方式很简单：
systemd-analyze cat-config systemd/coredump.conf 看输出是否包含 CoredumpCompress=yes，再执行 systemctl show --property=CoreDumpFilter,CoreDumpExe,CoreDumpSizeMax systemd-coredump 确认当前生效值。注意：即使 CoredumpCompress=yes，若 core 文件大小为 0 或被 CoreDumpSizeMax 截断（比如设成 2G 但实际写入前被 ulimit -c 限制为 0），压根本不会触发。

ulimit -c 为 0 时 systemd-coredump 完全不生成文件

这是最常被忽略的前提条件。systemd-coredump 不是独立捕获器，它依赖内核在进程收到 SIGSEGV 等信号后、按传统方式调用 kernel.core_pattern 触发。而内核是否写 core，第一道闸门就是进程自身的 RLIMIT_CORE（即 ulimit -c）。哪怕 systemd-coredump 服务正在运行、CoredumpCompress=yes 也配置正确，只要进程启动时 ulimit -c 0，内核连文件都不创建，后续所有逻辑都跳过。

排查要点：

• 对服务单元，检查 LimitCORE= 是否显式设为 0 或未设置（默认继承父进程）
• 对交互式 shell 启动的程序，运行前先执行 ulimit -c unlimited
• systemd 服务中若用 ExecStartPre=/bin/sh -c 'ulimit -c unlimited' 无效——ulimit 是 shell 内置命令，不能通过 exec 跨进程生效；必须用 LimitCORE=infinity 单元配置项

压缩失败的真实报错藏在 journalctl -t systemd-coredump 里

systemd-coredump 不会把压缩错误打到应用日志，也不会返回非零退出码给上层。失败时唯一线索是 journal 中带 systemd-coredump 标签的日志，尤其是含 Failed to compress core 或 zstd: failed to compress 的条目。常见原因有：

• 磁盘满或 /var/lib/systemd/coredump/ 所在分区只剩不到 100MB，zstd 默认需要临时空间
• zstd 命令不可用（例如 minimal 系统没装 zstd 包），此时即使 CoredumpCompress=yes 也会静默退化为不压缩
• core 文件被其他进程（如杀毒软件、备份工具）占用，导致 zstd -T0 调用时 open() 失败

临时验证可手动跑：
zstd -T0 /var/lib/systemd/coredump/core.xxx.xxxx -o /tmp/core.xxx.zst，看是否报错。

压缩性能与 ulimit 的隐式关联：内存限制影响 zstd 启动

很多人以为 ulimit 只管 core 文件大小，其实 RLIMIT_AS（地址空间）和 RLIMIT_DATA（数据段）也会影响压缩过程。systemd-coredump 在 fork 出 zstd 子进程时，子进程继承父进程（即 systemd-coredump 进程）的资源限制。如果该进程被 systemd 用 MemoryLimit= 或 LimitAS= 严格约束，而 zstd 在高压缩比模式下需要较多内存，就会直接 fork: Cannot allocate memory 或压缩中途 killed。

典型现象：

• 小 core（500MB）失败，journal 显示 Failed to execute compression command
• systemctl show systemd-coredump | grep LimitAS 返回非 0 值（如 LimitAS=1G）
• 临时放宽：sudo systemctl set-property systemd-coredump MemoryLimit=（清空限制）再试

真正难调试的是：这些限制可能来自 /etc/systemd/system.conf 的 DefaultLimitAS=，而非单个服务配置——它会批量作用于所有 unit，包括 coredump。

到这里，我们也就讲完了《systemd-coredump压缩失败怎么解决》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！