logrotate日志轮转失效主因是服务未重开日志：需正确配置postrotate发送USR1信号（注意pid路径、权限、服务支持），合理选用create或copytruncate策略，并通过inode变化、mtime更新和status文件验证实效性。
这个问题基本就是服务没收到重开日志的信号，或者收到了但失败了。logrotate 把旧文件 rename 掉、新建了空文件，但 nginx/apache/自研服务这些进程还握着原来的文件描述符在写，根本不知道有新文件——除非你明确告诉它“换文件写”。
postrotate 脚本里 kill -USR1 为什么总不生效
USR1 是 nginx、rsyslog 等服务的标准重开日志信号，但它不是发出去就完事的。常见失效点：
- pid 文件路径错：比如
/var/run/nginx.pid实际在/run/nginx.pid（systemd 环境下更常见），cat /var/run/nginx.pid直接报错 - 权限不够：脚本以 root 执行，但 pid 文件属组是
www-data，且没读权限；或进程跑在非 root 用户下（如systemctl --user），kill被拒绝 - 服务没监听 USR1：某些 Java 应用或自研 daemon 根本不处理这个信号，发了也白发
- 脚本非零退出中断整个轮转：比如
kill -USR1 $(cat /var/run/nginx.pid)因 pid 文件不存在而报错，导致后续 compress、rotate 全部跳过
正确写法必须带防御逻辑：
postrotate
if [ -f /run/nginx.pid ]; then
kill -USR1 $(cat /run/nginx.pid) 2>/dev/null || true
fi
endscript
sharedscripts 导致 postrotate 里 $1 不可用
默认开启 sharedscripts，意味着一个配置块里多个日志文件（比如 /var/log/nginx/*.log）轮转完只执行一次 postrotate。这时 $1 是空的——它只在非 shared 模式下才代表当前被轮转的旧文件路径。
所以别在 sharedscripts 下写依赖 $1 的命令，比如：
- ❌
gzip -d $1（$1为空，报错） - ✅
systemctl reload nginx（不依赖路径，安全）
如果真要对每个文件单独处理（比如按名触发不同脚本），就得关掉 sharedscripts，并确保 postrotate 块内逻辑能处理单个文件上下文。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
create 和 copytruncate 的选择直接影响新日志是否可写
create 是默认策略：轮转后新建空日志文件，靠服务自己重开（发 USR1/HUP）。但它要求服务支持重开，否则新日志永远没人写。
copytruncate 是兜底方案：先复制当前日志内容到归档文件，再清空原文件。这样服务始终往同一个 inode 写，完全不用管信号。但它有风险：
- 复制和清空之间可能丢几行日志（毫秒级窗口）
- 对超大日志（>10GB）复制操作本身会卡住 I/O，影响业务
- 不能和
create共存，配置里写了copytruncate就自动忽略create
判断用哪个：
- nginx/apache/rsyslog → 优先
create+ 正确postrotate - Java/Python 自研服务（没监听信号）→ 老实用
copytruncate
验证轮转是否真正生效的三个关键检查点
别只看归档文件有没有生成，重点确认新日志是否在持续追加：
- 查新文件 mtime：
stat /var/log/nginx/access.log，轮转后这个时间应该很新（比如几分钟内） - 查文件 inode：
ls -i /var/log/nginx/access.log，轮转前后 inode 号必须不同（create模式）或相同（copytruncate模式） - 实时观察写入：
tail -f /var/log/nginx/access.log，发个 curl 请求，看有没有新条目进来
最常被忽略的是状态文件 /var/lib/logrotate/status —— 它记录上次轮转时间，如果这里的时间远早于预期，说明 cron 没跑、配置没加载、或某次轮转因错误静默失败了。别跳过这行检查。
