logrotate 配了 size 仍不轮转：先核对程序何时运行

日志配置已经写了 size 100，文件超过 100 字节以后却没有出现轮转归档。若日志继续增长，而 logrotate 还没被调度执行，这种现象符合它的工作方式：它在每次运行时检查文件，处理完便退出，不会常驻等待文件越过阈值。

适用场景是 Linux 上通过 cron、anacron 或 systemd timer 调用 logrotate。先核对调用时间和实际配置，再决定是否缩短执行间隔；单独把 size 改小不会增加检查次数。

区分“尚未检查”和“检查后未轮转”

查看系统实际使用的调度入口和执行记录：是发行版提供的定时器、周期任务，还是自行配置的任务？确认最近一次执行时间、执行结果，以及入口传给 logrotate 的配置文件。不要只根据 /etc/logrotate.d/ 中有一个文件，就认定它已被当前入口包含。

如果下一次执行还没到，日志超过阈值并不表示配置失败。如果任务已经运行但报错，则按错误处理配置语法、路径和访问权限。若任务显示成功却跳过目标日志，继续检查有效规则及跳过理由。

可以使用当前系统支持的 debug 模式查看判定过程。下例采用常见主配置路径，实际路径应与调度入口一致：

sudo logrotate --debug /etc/logrotate.conf

debug 模式只输出诊断信息，不改动日志，也不更新状态文件。因此看到“将轮转”不能当作已经完成轮转。诊断可能包含日志路径和配置细节，应在受控终端查看。

若交互检查通过而定时任务仍失败，要比较执行用户、配置入口及服务访问限制。手动使用更高权限读到了文件，不等于原来的调度环境也能访问。应修正必要的访问范围，避免直接取消所有限制。

size、maxsize 和 minsize 的条件不同

size 100 中没有单位后缀，表示 100 字节。下面是单纯按尺寸判定的配置示例，路径和阈值需按实际日志调整：

/var/log/example/app.log {
    size 100M
    rotate 3
    compress
}

size 100M 在程序运行时检查是否超过这个尺寸。rotate 3 控制保留轮转文件的数量，compress 控制压缩；它们都不设置任务执行频率。保留数量耗尽时，旧归档可能被删除，修改前应确认日志留存要求和备份安排。

如果还要保留按时间轮转的规则，需要按目的选择尺寸选项：

• size 与 daily、weekly 等时间间隔选项互斥，后指定的选项有优先权，不宜随意叠加。
• daily 配合 maxsize 100M，可以在达到每日条件时轮转，也能在下一次检查发现文件过大时提前轮转。
• daily 配合 minsize 100M，要求时间条件和最小尺寸条件都满足，适合避免把太小的日志也按天轮转。

即使用了 maxsize，它仍然只在 logrotate 被调用时检查。任务每天运行一次，文件可能在两次检查之间远超过阈值；这里的尺寸规则不提供文件大小的硬上限。

需要更及时轮转时，修改现有调度

先保存当前规则与调度配置，再根据日志增长速度、磁盘余量和轮转脚本成本选择检查间隔。在使用 cron 的系统中调整对应任务；在使用 systemd timer 的系统中调整实际启用的 timer。应沿用一个明确的调度入口，避免新增一个任务后把原来的入口也留着同时运行。

更频繁的调用会增加检查、轮转、压缩及相关脚本的执行机会。改变频率前，应确认应用的日志重新打开方式已配置正确，并评估这些动作对服务的影响。出现异常时恢复保存的规则与调度，随后核对应用仍在写入预期日志；恢复配置不会自动还原已经删除的旧归档。

不要把周期性执行 --force 当作尺寸轮转的替代方案。它会强制轮转，绕过原本的必要性判断；也不要为了并发任务方便就关闭状态文件锁。当前 logrotate 默认通过状态文件锁防止并行执行，锁拿不到时会失败，应先排除重复入口或尚未结束的任务。

调整后观察真实定时执行记录：任务按预期间隔运行，超过尺寸的日志在后续检查时产生归档，应用继续写入活动日志，归档数量符合保留规则。若业务要求一越过阈值就立即切分，需要另行选择应用自身的轮转能力；缩短轮询间隔只能缩小检查之间的时间窗口。