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 能一眼看出异常大的未压缩归档。
