Jenkins logrotate失效排查求助：日志未按配置规则轮转

遇到过好几个类似的案例，咱们一步步拆解问题：

1. 先确认配置语法无错误 #

logrotate对语法很敏感，哪怕一个符号错了都可能导致规则不生效。先跑调试模式检查：

logrotate -d /etc/logrotate.d/jenkins  # 替换成你的Jenkins配置文件实际路径

这个命令会模拟执行但不实际修改文件，仔细看输出里有没有报错——比如有些旧版本的logrotate不支持size=+4096k这种带+的写法，换成size 4096k试试（意思是文件超过4096k就触发轮转）。

2. 手动执行并查看详细日志 #

直接用verbose模式手动执行一次，看具体为什么不触发轮转：

logrotate -v /etc/logrotate.d/jenkins

重点看输出里关于/var/log/jenkins/jenkins.log的判断逻辑，比如会不会显示“log size is below threshold”（这显然和你的1.4GB文件矛盾，说明配置解析有问题），或者提示“already rotated today”——如果是后者，说明logrotate的状态文件记录有异常。

3. 分析logrotate状态文件 #

你提供的状态信息是-- version 2 "/var/log/jenkins/jenkins.log" 2019-12-9-3:21:1，这里的时间是上次轮转的记录。如果系统时间曾回退过，或者状态文件损坏，logrotate会误认为已经完成过轮转。可以先备份状态文件再清空试试：

cp /var/lib/logrotate.status /var/lib/logrotate.status.bak
echo "" > /var/lib/logrotate.status

然后再手动执行logrotate，看是否触发轮转。

4. 检查文件权限与SELinux上下文 #

logrotate默认以root用户运行，确保它对Jenkins日志目录和文件有读写权限：

ls -l /var/log/jenkins/

如果是RHEL/CentOS这类开启SELinux的系统，还要检查文件上下文是否正常：

ls -Z /var/log/jenkins/

如果上下文不是system_u:object_r:var_log_t:s0，可以用restorecon -Rv /var/log/jenkins修复。

5. 排查copytruncate的潜在问题 #

你的配置用了copytruncate，这个选项是先复制日志内容到新文件，再截断原文件。偶尔会出现logrotate无法正确截断的情况（比如Jenkins在截断瞬间高频写日志）。可以临时把copytruncate替换成create 644 jenkins jenkins（指定日志文件的属主属组），然后手动执行——不过要注意：替换后Jenkins可能需要重启才能重新打开新的日志文件（因为原文件被重命名后，Jenkins的文件句柄还指向旧文件），操作前最好先停Jenkins。

6. 确认logrotate的触发逻辑 #

虽然你的配置是size触发，但如果logrotate的cron脚本里加了额外参数（比如-s指定了其他状态文件），或者全局配置覆盖了你的规则，也可能出问题。检查/etc/cron.daily/logrotate脚本的内容，看有没有限制规则生效的参数。

内容的提问来源于stack exchange，提问作者rovaru