直接用 logrotate 配置最稳妥，支持轮转、压缩、清理及通知 nginx 重开日志；需确认日志路径、运行用户和 pid 文件位置，正确编写 /etc/logrotate.d/nginx 配置并验证生效。
直接用 logrotate 配置，别动 Nginx 自身配置 —— 它不负责保留天数，只负责写日志。
确认 logrotate 已安装且路径正确
绝大多数发行版（Ubuntu 24.04、CentOS 7+、Debian 12）默认已装 logrotate。运行以下命令验证：
which logrotate
如果返回空，按系统补装：
- Ubuntu/Debian：
sudo apt install logrotate - CentOS/RHEL：
sudo yum install logrotate或sudo dnf install logrotate
注意：不要用 nginx -s reopen 替代 kill -USR1，后者才是标准信号；前者在无 pid 文件或权限不足时会静默失败。
/etc/logrotate.d/nginx 配置必须包含 postrotate 通知
缺了 postrotate 段，Nginx 不会关闭旧文件句柄，导致磁盘空间不释放（即使日志被重命名，进程仍在往旧文件写）。正确写法示例：
/var/log/nginx/*.log {
daily
missingok
rotate 30
compress
delaycompress
notifempty
create 0640 www-data adm
sharedscripts
postrotate
[ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid)
endscript
}
关键点：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
delaycompress：避免刚轮转就压缩，留出排查窗口；若删掉它，.1会立刻变.1.gz，但.2.gz等仍保留未压缩 -
sharedscripts：确保多个匹配文件（如access.log和error.log）只发一次USR1，否则可能触发两次 reload -
www-data是 Debian/Ubuntu 默认用户；RHEL/CentOS 请换成nginx或查ps aux | grep nginx确认 worker 进程属主
测试配置是否生效，别只看 cron
logrotate 本身不主动运行，靠 cron.daily 触发（通常在凌晨 6:25 左右），你改完配置后必须手动验证：
sudo logrotate -f /etc/logrotate.d/nginx
执行后检查三件事：
-
ls -lt /var/log/nginx/：应看到access.log.1、error.log.1等新文件 -
lsof -p $(cat /var/run/nginx.pid) | grep log：输出里不应再出现access.log.1类旧路径（说明句柄已切换） -
zcat /var/log/nginx/access.log.1.gz | head -n1（如果启用了compress）：能正常解压读取，证明压缩逻辑没坏
常见失败现象：logrotate 执行无报错但日志没切 —— 大概率是 postrotate 里 kill -USR1 权限被拒或 /var/run/nginx.pid 路径不对（Nginx 可能用 /run/nginx.pid）。
rotate 数值不是“保留天数”，而是“归档文件个数”
rotate 30 表示最多存 30 个归档（.1 到 .30），和 daily 搭配≈30 天，但实际取决于轮转频率。如果你改成 weekly，rotate 30 就是保留 30 周 ≈ 210 天。
真正影响磁盘占用的是：compress + delaycompress 组合是否启用、日志原始体积、以及是否混用 size 100M 这类条件（不推荐和 daily 同时用，易冲突）。
容易被忽略的细节：logrotate 每次只处理满足条件的文件；如果某天 access.log 为空且启用了 notifempty，当天就不会生成 .1，后续编号会跳（比如昨天是 .5，今天直接 .6），rotate 30 依然有效 —— 它管的是现存归档总数，不是连续序号。
