logrotate按size切割未生效，主因是daily与size共存时逻辑为“或”非“且”，应单独用size或改用minsize+daily；还需确认cron是否运行、权限是否足够、配置文件命名正确及size单位精确。
logrotate 按 size 切割没生效，大概率是 daily（或其他时间策略）和 size 同时存在，而 logrotate 把它们当“或条件”处理——只要有一个不满足，就不触发轮转。
logrotate 的 size 和 daily 是“或关系”，不是“且关系”
很多人写成这样：
/var/log/myapp.log {
daily
size 1G
rotate 7
compress
}
以为“每天一次，或者达到 1G 就切”，实际逻辑是：“满足 daily 或 满足 size 1G 才轮转”。但 daily 每天只在 cron 触发时判断一次时间点（比如凌晨 6:25），如果那天日志始终没到 1G，它就不会切；而如果你删了旧日志、重启了 logrotate，它也不会主动补触发——它不监控文件增长，只按 schedule 跑。
-
size 1G单独用才可靠：去掉daily，只留size 1G，它会在每次 cron 运行时检查当前文件大小，超了就切 - 想兼顾“至少一天切一次，但大流量时提前切”？用
minsize 500M+daily：表示“满 500M 且已过一天才切”，避免小日志堆积太久 -
minage 1可配合使用：强制至少保留 1 天再轮转，防止高频写入下被反复切（尤其搭配copytruncate时）
logrotate 根本没运行，size 设置再对也白搭
很多容器环境、精简版系统（如 Alpine）、或手动禁用 cron 的机器，/etc/cron.daily/logrotate 压根不会执行。logrotate 不是守护进程，它依赖外部调度。
- 确认 cron 是否启用：
systemctl is-active cron或systemctl is-active crond - 检查 cron 日志：
grep logrotate /var/log/syslog或journalctl -u cron | grep logrotate - 手动测试是否能跑：
logrotate -f /etc/logrotate.d/myapp（加-f强制执行，看有没有报错） - 容器里没 cron？得自己加 crond，或改用
logrotate -f放进应用启动脚本里定期调用
文件大小判断被缓存 or 权限挡住了
logrotate 在判断 size 前会 stat 文件，但某些场景下看到的大小不是真实写入量：
- 用
nohup ./app > app.log &启动的服务，日志文件可能被内核缓冲，stat返回的 size 比磁盘实际占用小（du -h app.log和ls -lh app.log不一致时特别明显） - logrotate 进程没权限读目标日志？检查
ls -l /var/log/myapp.log，确保root（默认运行用户）能访问 - 用了
copytruncate？它先复制再清空，但复制过程不改变原文件 size 判断逻辑；不过若复制失败（磁盘满、权限不足），整个轮转会中止，且默认不报错 - 配置文件放在
/etc/logrotate.d/下但带扩展名（如myapp.conf）？logrotate 会跳过，需重命名为myapp（无后缀）
最常被忽略的一点：logrotate 的 size 是按字节比对的，1G = 1073741824 字节，不是 1000³；写成 1000M 更直观，也更少出错。别信直觉，用 logrotate -d /etc/logrotate.d/myapp 看调试输出里实际读到的 size 值，那才是它决策的依据。
