size参数是防止单个应用日志突发暴涨最直接有效的方式——它不依赖时间，只看文件体积，一到阈值立刻轮转，避免日志在几小时内冲爆磁盘；daily则每天仅检查一次，响应滞后，无法应对高并发或异常频发场景。
用 size 参数是防止单个应用日志突发暴涨最直接有效的方式——它不依赖时间，只看文件体积，一到阈值立刻轮转，避免日志在几小时内就冲爆磁盘。
为什么 size 比 daily 更适合防暴涨
daily 是每天固定时间检查一次，不管当天写了多少日志；而 size 是实时监控，只要日志文件达到设定大小（比如 100M），logrotate 就立即触发轮转。对调试中、高并发或异常频繁的应用来说，daily 完全来不及响应——可能凌晨刚轮转完，上午就涨到 5GB，下午根分区就告警了。
注意：size 和 daily 互斥，配置里同时写两者，logrotate 只认 size，daily 被自动忽略。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
关键参数怎么设才稳
- size 50M 或 size 100M：推荐起点。50M 适合日志敏感型服务（如审计、安全类）；100M 更适配 API 网关、中间件等吞吐量大的场景
- rotate 12–24：保留 12～24 份归档，兼顾排查深度和磁盘压力。别设为 0，否则旧日志不清理，照样撑满
- compress + delaycompress：压缩省空间，delaycompress 确保 auditd、rsyslog 这类还在写旧日志的服务不因压缩被锁住
- missingok + notifempty：防止日志路径不存在或为空时中断整个 logrotate 流程
- create 0644 user group：轮转后新建日志文件，权限和属主必须明确，否则应用可能因无权限写入而丢日志
实战配置示例（以自定义应用 myapp 为例）
在 /etc/logrotate.d/myapp 中写入：
/var/log/myapp/*.log {
size 100M
rotate 18
compress
delaycompress
missingok
notifempty
create 0644 myapp myapp
sharedscripts
postrotate
/bin/kill -USR1 `cat /var/run/myapp.pid 2>/dev/null` 2>/dev/null || true
endscript
}
说明：这里用 USR1 通知 myapp 重新打开日志文件（需应用本身支持）；若不支持信号，可改用 copytruncate——先复制再清空原文件，但有极小概率丢失最后几行日志。
验证与上线前必做三步
- 运行
sudo logrotate -d /etc/logrotate.d/myapp查语法错误，确认输出无 “error” 或 “warning” - 手动触发一次：
sudo logrotate -f /etc/logrotate.d/myapp，检查/var/log/myapp/下是否生成xxx.log.1，原日志是否清空或截断 - 模拟写入测试：用
yes "test log" | head -n 100000 >> /var/log/myapp/app.log快速撑大文件，观察是否在达到 100M 后自动轮转（可用du -h实时监控）
