Linux 日志轮转失败导致磁盘占满的处理

logrotate 配置语法错误会静默跳过而非报错退出，需用 -d 模式调试并检查 error/ignoring 提示；常见问题包括括号缺失、拼写错误、路径无效、权限不足、未处理文件占用、压缩失败及磁盘满导致临时文件创建失败。

logrotate 配置文件语法错误导致轮转跳过

logrotate 不会报错退出，而是静默跳过有语法问题的配置段。常见错误包括：missing } at end of config、unknown option 'copytruncatee'（拼写多了一个 e）、compresscmd 路径写错但未校验。用 logrotate -d /etc/logrotate.conf 可看到详细跳过原因，重点关注输出里是否出现 error: 或 ignoring 字样。

• 运行 logrotate -d /etc/logrotate.d/myapp 单独调试应用配置，比全量调试更清晰
• 检查 daily/weekly 是否与 dateext 冲突（如启用了 dateext 但没配 dateformat，部分旧版 logrotate 会拒跑）
• 确认日志文件路径在配置中是绝对路径，且 logrotate 进程有读取权限（尤其当日志属 root:adm 但配置由非 root 用户维护时）

日志文件被进程持续占用且未触发 copytruncate

如果应用不支持 reopen 日志（比如某些 Go 程序或 systemd-journald 管理的服务），而配置里又没加 copytruncate，logrotate 会重命名原文件但无法清空它——因为文件句柄仍被进程持有，磁盘空间不会释放。此时 du -sh /var/log/*.log 和 lsof +L1 结果对不上：前者显示大文件，后者可能列出已删除但未释放的 deleted 条目。

• 加 copytruncate 是最直接的补救，但它不能保证原子性；若日志写入频繁，可能丢几行
• 更稳妥的方式是配合 postrotate 发送信号，例如 kill -USR1 `cat /var/run/nginx.pid` 让 Nginx 重新打开日志文件
• systemd 服务建议用 systemctl kill --signal=SIGUSR1 myapp.service 替代硬 kill

rotate 后旧日志未压缩或未删除，堆积大量 .1 .2.gz 文件

常见于配置了 rotate 5 但忘了配 compress，或压缩命令失败（如 gzip 不在 PATH、磁盘满导致压缩中途退出）。结果是每次 rotate 都生成新 .1，旧的 .2～.5 留着不动，ls -S /var/log/ | head -10 能一眼看出异常大的未压缩归档。

秘塔写作猫

秘塔写作猫是一个集AI写作、校对、润色、配图等为一体的创作平台

下载

• 检查 compresscmd 和 uncompresscmd 的值是否匹配真实命令路径，例如 /bin/gzip 而不是 gzip
• delaycompress 和 compress 一起用时，只有上一轮的 .1 会被压缩成 .1.gz，当前轮的 .1 暂时不压——这是预期行为，别误判为失败
• 用 logrotate -f -v /etc/logrotate.d/myapp 强制跑一次并看输出，确认是否出现 compressing log with 或 failed to compress

磁盘已满时 logrotate 自身无法写入临时文件

logrotate 在 rotate 前会尝试创建临时文件（如 /var/log/app.log-20241015），如果根分区只剩几十 MB，这步就会失败，并留下 logrotate state file 时间戳未更新，后续再也不会触发 rotate。此时 df -h 显示 / 或 /var 100%，但 logrotate -d 可能只报 cannot create temp file 并静默退出。

• 先人工清理：用 journalctl --disk-usage 查 systemd 日志占比，journalctl --vacuum-size=200M 释放空间
• 删 /var/log/journal/*/*.journal~（已标记删除的 journal 备份）和 /var/log/*.gz 中最老的几个
• 临时改配置把 olddir 指向有空间的分区（如 /home/logrotate-old），等恢复后再调回