logrotate未自动轮转是因定时机制失效。先检查systemd timer是否启用（systemctl list-timers | grep logrotate），再排查cron.daily跳过逻辑、配置路径与语法、日志文件权限及状态文件更新情况。
logrotate 没轮转，日志越积越多，但手动运行 logrotate -f 又能成功——这说明配置本身没问题，问题出在“没人按时叫它干活”。核心是确认定时触发机制是否真正生效。
检查 systemd timer 是否启用（新版系统默认）
多数现代发行版（如 CentOS 8+/RHEL 8+、Ubuntu 20.04+）已用 systemd timer 替代 cron daily。直接查是否注册并启用：
- 运行
systemctl list-timers | grep logrotate，看是否有logrotate.timer且状态为enabled、下次触发时间合理 - 若没看到，执行
systemctl enable --now logrotate.timer启用 - 查看详细状态：
systemctl status logrotate.timer和systemctl cat logrotate.service
检查 cron.daily 是否被跳过或失效
老系统或部分定制环境仍依赖 cron。但脚本里常有防冲突逻辑：
- 打开
/etc/cron.daily/logrotate，确认开头没有exit 0类判断（比如检测/run/systemd/system存在就提前退出） - 手动执行该脚本：
sudo bash -x /etc/cron.daily/logrotate，观察是否卡在某处（如权限、路径、anacron缺失） - 确认 cron 服务在运行：
systemctl is-active cron或systemctl is-active crond
验证配置加载路径和语法
即使定时器跑起来了，也可能根本没读到你的规则：
- 确保自定义配置放在
/etc/logrotate.d/下（不能放错目录，也不能加后缀如.conf） - 检查主配置
/etc/logrotate.conf是否包含include /etc/logrotate.d（注意路径拼写和缩进） - 用调试模式验证加载效果：
logrotate -d /etc/logrotate.conf 2>&1 | grep "rotating pattern"，看目标日志是否出现在匹配列表中
确认日志文件状态与权限
logrotate 不会为不存在的路径或无权限访问的文件执行轮转：
- 确认日志路径真实存在，且 logrotate 进程（通常以 root 身份运行）有读写权限
- 检查
/var/lib/logrotate/status文件，看对应日志最后处理时间是否更新（若长期没变，说明未触发） - 如果应用自身持续打开日志文件（如 Nginx、Java 服务），需配
copytruncate或在postrotate中发信号重开句柄，否则轮转后新日志可能写入旧文件副本
