logrotate 无“单次轮转最大文件大小”参数，真正控制单个日志文件最大体积的是 size 参数，如 size 100M，表示当前日志达该值即轮转；需配合 create、missingok、compress、postrotate 等使用才生效。
Logrotate 本身不提供“单次轮转最大文件大小”这一参数——它没有类似 max-file-size-per-rotation 的配置项。你真正要控制的，是触发轮转的阈值，也就是日志文件在被轮转前允许增长到的最大体积。这个阈值由 size 参数设定，它是防止单个日志文件无限膨胀最直接、最有效的手段。
用 size 参数设定轮转触发体积
size 不是限制“轮转后生成的文件大小”，而是定义“当前正在写入的日志文件达到多大时，立刻执行轮转”。一旦达到该值（例如 size 100M），logrotate 就会把当前日志重命名（如 app.log → app.log.1），再新建一个空的 app.log 继续接收新日志。
- 写法示例：
size 50M、size 1G、size 200k（支持 K/M/G 单位） - 单位不区分大小写，但建议统一用大写（如
M）避免歧义 - 该参数与
daily、weekly等时间条件互斥；只要用了size，logrotate 就只按体积判断，不再看时间
为什么不能靠 rotate 或 compress 控制“单次轮转大小”
rotate N 控制的是保留多少个归档文件（如 app.log.1 到 app.log.N），不是单个文件大小；compress 只影响归档后的压缩行为，对原始日志体积毫无约束。真正决定“一个日志文件最多写多大才停”的，只有 size。
- 若没设
size，又没配时间策略，日志可能持续写入数天甚至数月，单个文件轻易突破 10GB+ - 若只设
daily，但某天突发流量导致日志两小时涨到 8GB，它仍会等到次日凌晨才轮转——中间已埋下磁盘爆满风险
必须搭配的关键参数才能让 size 生效
单独写 size 100M 是不够的。以下参数需组合使用，否则可能轮转失败、权限错误或服务继续往旧文件写：
-
create 0644 root root：确保轮转后新建的日志文件权限正确，服务能正常写入 -
missingok和notifempty：避免因路径不存在或日志为空导致 logrotate 中断退出 -
compress+delaycompress：压缩旧日志节省空间，且延迟压缩可避免服务还在写.1文件时就被 gzip 锁住 -
postrotate ... endscript：通知服务重新打开日志文件（如systemctl kill --signal=SIGHUP myapp），否则进程仍向已重命名的旧文件句柄写入，新日志“消失”
验证 size 是否实际起作用
别等 cron 自动运行，改完配置立即测试：
- 语法检查：
sudo logrotate -d /etc/logrotate.d/myapp（显示执行逻辑，不真实轮转） - 强制触发一次：
sudo logrotate -f /etc/logrotate.d/myapp，观察是否生成.1文件 - 手动灌入日志测试：用
yes "test" | head -n 1000000 >> /path/to/app.log快速撑大文件，再运行-f看是否及时响应
