logrotate不会自动管理应用日志，必须手动配置并确认调度启用，否则磁盘易被撑爆；需检查systemd timer或cron、测试配置、验证postrotate脚本及句柄更新。
logrotate 不会自动管你的应用日志，必须手动写配置文件并确认调度已启用，否则磁盘迟早被撑爆。
怎么确认 logrotate 真正在跑
装了 ≠ 在用。很多系统（尤其是容器或最小化安装）压根没激活 daily 调度：
- 运行
sudo systemctl list-timers | grep logrotate，有输出才说明 systemd timer 已启用；若无，检查/etc/cron.daily/logrotate是否存在且可执行 - 手动模拟一次：
sudo logrotate -d /etc/logrotate.conf，重点看有没有error或permission denied - 查状态文件：
cat /var/lib/logrotate/status，最后一行时间戳是否在最近 24 小时内？不是，说明 cron 没跑成
为自定义日志写独立子配置文件
别改 /etc/logrotate.conf，直接往 /etc/logrotate.d/ 下建新文件，比如 /etc/logrotate.d/myapp：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 路径必须写绝对路径，例如
/var/log/myapp/app.log，不能用通配符（如*.log）除非你真需要批量匹配 - 必须用大括号包裹规则块，且至少含一个触发条件：
daily、weekly或size +100M（注意是+，表示“超过”才触发） -
rotate 7是保留份数，不是天数；delaycompress必须配合compress使用，否则压缩行为不可控 -
create 0644 myuser mygroup中的用户和组，必须和你的应用进程实际运行身份一致，否则新日志创建失败
postrotate 脚本为什么总不生效
它失败时 logrotate 默认沉默，但旧日志句柄不会释放，导致新内容继续写进 .1 文件——看起来轮转了，其实还在涨：
- 务必加
sharedscripts，否则每个匹配到的日志文件都会单独执行一遍postrotate，容易重复发信号 - 命令必须用绝对路径，比如
/bin/kill -USR1 `cat /var/run/myapp.pid 2>/dev/null` || true，不能写kill，也不能省略|| true - 不要用
systemctl reload myapp，某些服务 reload 会丢日志；USR1是标准做法，Nginx、rsyslog、Java 应用（若支持）都认这个 - 验证句柄是否更新：
lsof -p $(cat /var/run/myapp.pid) | grep log，确认进程打开的是新日志文件，不是app.log.1
按大小还是按时间轮转？选错就白配
高写入服务（如 API 网关、消息队列）日志量波动大，只配 daily 可能单个日志涨到几 GB 才切；而 size +100M 能及时控制体积：
-
size和daily是互斥的——logrotate 只认第一个出现的条件，不要同时写 -
size +100M表示“超过 100MB 就触发”，size 100M表示“恰好等于才触发”，几乎不可能命中 - 搭配
copytruncate更稳妥：它先复制再清空原文件，不依赖服务 reload，适合无法发送 USR1 的老旧应用 - 但
copytruncate有风险：复制和清空之间可能丢少量日志（毫秒级），生产环境需权衡
最常被忽略的其实是 include /etc/logrotate.d 这行是否被注释掉——它一被注释，整个 /etc/logrotate.d/ 目录下的配置全失效，查半天发现规则根本没加载。
