压缩失败时应先确认CoredumpCompress是否真正启用：检查systemd-analyze cat-config输出及journalctl -t systemd-coredump日志，同时验证ulimit -c、磁盘空间、zstd可用性及内存限制。
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。