size参数是最有效的防止单个日志文件无限膨胀的方法，因其实时监控文件体积、达阈值即轮转，比daily更可靠；需搭配rotate、compress、missingok、create及postrotate等参数才能生效，并须通过systemctl kill或kill -usr1通知服务重载日志。
直接用 size 参数是最有效的防止单个日志文件无限膨胀的方法，尤其适合写入不规律、突发流量大或调试阶段日志量激增的服务。
为什么 size 比 daily 更可靠
daily 只在每天固定时间检查一次，如果某次请求风暴让日志在两小时内涨到 5GB，它不会提前处理；而 size 是实时监控文件体积，一达到阈值（比如 100M）就立刻轮转，从源头掐断“撑爆磁盘”的风险。
- size 和 daily 互斥，logrotate 遇到 size 就自动忽略 daily
- 推荐设为 size 100M 或 size 500M，兼顾可读性与安全性
- 对 audit.log、Core 服务日志、ROS2 日志这类易暴涨的场景，size 是首选
配置 size 轮转的关键参数组合
仅写 size 不够，必须搭配几个核心参数才能真正落地生效：
- size 100M：触发条件，文件超 100MB 立即轮转
- rotate 14：最多保留 14 个归档，避免历史文件越积越多
- compress + delaycompress：节省空间，且延迟压缩确保服务还在写旧日志时不冲突
- missingok + notifempty：防止因路径不存在或日志为空导致报错中断
- create 0644 root root：轮转后新建空日志，权限正确，服务能继续写入
必须加 postrotate 通知服务重载日志
轮转只是把 app.log 改名为 app.log.1，但进程还拿着原文件句柄往里写——若不通知，新日志会继续写进已归档的旧文件，导致排查时“找不到最新记录”。
- 对 systemd 服务（如 core、auditd、rsyslog），用：
systemctl kill --signal=SIGHUP 服务名 - 若服务支持 USR1（如 Nginx、某些 Java 应用），可用：
kill -USR1 $(cat /var/run/nginx.pid) - 切勿用 restart，会中断日志流，丢失中间事件
验证和强制测试方法
改完配置别急着等 cron，立刻验证是否生效：
- 语法检查：
sudo logrotate -d /etc/logrotate.d/core（只打印逻辑，不执行） - 强制运行一次：
sudo logrotate -f /etc/logrotate.d/core，观察是否生成 .1 文件和压缩包 - 手动增大日志测试：
yes "test log" >> /var/log/core/app.log，直到超限触发轮转
