不能直接用logrotate的daily选项完事，因为Nginx进程仍持有原日志文件描述符，不发USR1或reopen信号则持续写入旧文件，导致切割失效、双写或日志丢失；必须配合postrotate中nginx -s reopen或kill -USR1，并正确配置create、sharedscripts、dateext等参数。
为什么不能直接用 logrotate 的 daily 选项就完事？
很多用户以为给 logrotate 配个 daily 就能自动按天切分 Nginx 日志，结果发现日志文件没重命名、旧日志还在写、甚至出现双写——根本原因是 Nginx 进程仍持有原日志文件的文件描述符，logrotate 的 movefirst 或默认 rename 操作后，Nginx 并不知道该换新文件写入。
必须配合 kill -USR1 通知 Nginx 重新打开日志文件，否则所有“切割”只是表面移动，实际写入仍在原文件里。
-
logrotate需配置create和sharedscripts，确保新日志权限正确且只执行一次 postrotate - postrotate 中必须调用
nginx -s reopen（推荐）或kill -USR1 $(cat /var/run/nginx.pid) - 若 Nginx 以非 root 用户运行（如 www-data），
logrotate脚本需有足够权限发送信号，建议用su切换用户
logrotate 配置文件怎么写才不丢日志？
典型错误是把 /var/log/nginx/*.log 写成通配符路径却不加 missingok，导致某天没有访问日志时 logrotate 报错退出，后续切割全部中断；另一个坑是没设 dateext，靠编号轮转（.1, .2）容易覆盖旧数据，无法按日期定位。
推荐配置片段（保存为 /etc/logrotate.d/nginx）：
/var/log/nginx/*.log {
daily
missingok
rotate 30
compress
delaycompress
notifempty
create 0644 www-data www-data
sharedscripts
dateext
dateformat -%Y%m%d
postrotate
if [ -f /var/run/nginx.pid ]; then
nginx -s reopen 2>/dev/null || true
fi
endscript
}
-
dateformat -%Y%m%d生成形如access.log-20241015的归档名，比默认-%Y%m%d%S更干净 -
delaycompress避免刚切完就压缩，方便排查当天问题 -
notifempty防止空日志触发无意义切割 - 务必确认
www-data是 Nginx worker 进程的实际运行用户，可通过ps aux | grep nginx查看
手动触发和验证切割是否生效？
别等凌晨 cron 自动跑——先用 logrotate -d /etc/logrotate.d/nginx 看调试输出，确认匹配到日志路径、执行了 postrotate；再用 logrotate -f /etc/logrotate.d/nginx 强制执行一次，观察行为是否符合预期。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
验证要点：
- 执行后原
access.log文件大小是否归零？用ls -l /var/log/nginx/access.log看 size - 是否有新文件如
access.log-20241015生成？用ls -t /var/log/nginx/*.log*排序查看 - 执行
lsof -p $(cat /var/run/nginx.pid) | grep log，确认 Nginx 打开的仍是access.log（而非旧的带日期后缀的文件） - 立刻 curl 一下站点，检查新
access.log是否有新增行，而不是写进归档文件里
systemd 环境下要注意 PID 文件位置
某些发行版（如较新 Ubuntu/Debian）用 systemd 管理 Nginx，/var/run/nginx.pid 可能不存在或被写入 /run/nginx.pid；更稳妥的方式是不用硬编码 PID 路径，直接用 nginx -s reopen——它会自己找 PID 文件位置。
如果 nginx -s reopen 报 nginx: [alert] kill(12345, 10) failed (3: No such process)，说明：
- Nginx 主进程已退出，但 worker 还在（罕见），先
systemctl restart nginx - 或
nginx命令不在$PATH中，logrotate 脚本里改用绝对路径：/usr/sbin/nginx -s reopen - SELinux 启用时可能拦截信号，临时用
setenforce 0测试是否为此原因
最常被忽略的是：logrotate 的执行用户（通常是 root）必须对 Nginx 配置和二进制文件有读取权限，否则 nginx -s reopen 会静默失败。
