应直接删除/var/lib/logrotate/status文件并让logrotate自动重建，但须先用lsof检查是否被占用；删除后通过logrotate -d调试确认“creating new state”，再用-vf验证轮转，同时确保目录权限为root可写。
直接删掉就行，logrotate 会自动重建，但得先确认没其他进程正在用它。
为什么不能直接编辑 /var/lib/logrotate/status
这个文件不是普通文本配置，而是 logrotate 自己维护的二进制状态数据库（实际是简单键值对格式，但结构敏感）。手动改错一个字符、多一个空行、或编码不对，就会导致 logrotate 启动时解析失败，报类似 error: bad top line in state file 或直接静默跳过轮转。它不校验内容合法性，只按固定格式读取 —— 所以“修复”不如“重建”可靠。
删之前必须检查是否有活跃的 logrotate 进程
如果 logrotate 正在运行中（比如 cron 刚触发、或你刚手动执行过），此时删掉 status 文件会导致它下次运行时状态错乱，可能重复轮转或漏轮转。
- 运行
ps aux | grep logrotate，看有没有非 grep 自身的进程 - 更稳妥：执行
sudo lsof /var/lib/logrotate/status，有输出说明正被占用 - 若有活跃进程，先等它结束；若卡死，用
sudo killall -9 logrotate终止
删除后怎么验证是否恢复正常
删完别急着等 cron，立刻用调试模式跑一次，观察是否能重建并正常匹配日志：
- 执行
sudo logrotate -d /etc/logrotate.conf - 重点看输出里有没有
acquired lock on state file和Reading state from file—— 如果后面跟着Creating new state，说明重建成功 - 再执行
sudo logrotate -vf /etc/logrotate.conf（强制 + 详细），确认实际轮转动作能走通 - 最后检查
ls -l /var/lib/logrotate/status，文件应存在且属主为 root
真正麻烦的不是 status 文件损坏本身，而是它常和另一个问题共存：/var/lib/logrotate/ 目录权限被意外改成非 root 可写。删完 status 后如果重建失败，第一反应不是重试，而是先跑一遍 sudo chown root:root /var/lib/logrotate && sudo chmod 755 /var/lib/logrotate。
