logrotate 依赖 cron 定时触发（通常每日凌晨执行），是否成功轮转及上次时间均记录在 /var/lib/logrotate/status 中，该文件是判断轮转状态的唯一可信依据。
系统日志填满后，logrotate 是否触发、何时触发、是否失败，全在 /var/log/logrotate.status 里记着
Linux 不会“自动处理”日志填满这件事——它靠 logrotate 定时轮转，而轮转是否成功、上次执行时间、哪些文件被处理过，都如实写进 /var/log/logrotate.status。这个文件就是唯一可信的“事后记录”。直接 cat /var/log/logrotate.status 就能看到每条日志路径对应的最后轮转时间；如果某条路径长期没更新，说明轮转卡住了或配置失效。
journalctl --disk-usage 显示的是 journald 实际占用，但不告诉你“为什么没清理”
journalctl --disk-usage 只输出当前 systemd 日志占多少空间，比如 Archived and active journals take up 1.2G in the filesystem. 它不记录“上次 vacuum 是谁触发的、有没有报错、是否被配额限制”。真要看决策过程，得查 journalctl -u systemd-journald --since "2 hours ago"，重点搜 vacuum、rotate、maxsize 相关行。常见失败原因：配置里设了 SystemMaxUse=50M，但磁盘只剩 40M，journald 就会拒绝写入并报 Failed to rotate logs, disk full —— 这类错误只出现在 journal 自身日志里，不在 logrotate.status 中。
被进程持续写入的日志文件，du 和 df 看起来矛盾？用 lsof +L1 找“已删但未释放”的句柄
- 现象：
df -h显示/var98% 满，du -sh /var/log/* | sort -hr加起来才 2G —— 差额就是“已被rm但仍有进程打开”的文件 -
lsof +L1（注意是大写 L 数字 1）能直接列出这类文件，输出形如：rsyslogd 1234 root 1w REG 253,0 8.2G 123456 /var/log/syslog (deleted) - 此时
df认为这 8.2G 还占着空间，du却扫不到它（因为目录项已删），只有重启rsyslogd或kill -HUP 1234才能真正释放
手动触发 logrotate 时加 -d 参数，才能看到它“打算做什么”而不是“做了什么”
想验证配置是否生效，别直接跑 logrotate /etc/logrotate.d/myapp —— 它默默执行完，失败也不报错。改用：logrotate -d /etc/logrotate.d/myapp。输出里会明确告诉你：“considering log /var/log/myapp/app.log”，“log needs rotating”，“rotating log /var/log/myapp/app.log”，甚至“skipping missing log file”。这些判断逻辑，才是系统“自动处理”的真实依据。漏掉 -d，你永远不知道它为什么跳过某个日志。
真正卡住系统的，往往不是日志本身有多大，而是轮转逻辑被权限、路径不存在、或残留句柄堵死；logrotate.status 和 lsof +L1 是唯二能交叉印证的线索，其他命令全是间接推断。
