判断nginx日志是否成功reopen，核心是检查worker进程实际打开的文件描述符：用lsof -p $(cat /var/run/nginx.pid) | grep 'access.log|error.log'确认是否已切换至新文件，而非仅依赖文件名变更；若inode未变或du显示重命名文件仍在增长，说明reopen未生效。
直接看日志文件是否还在被 Nginx 进程持有——这是最核心的判断依据。不是只看文件名有没有变，而是看底层文件描述符（fd）是否已切换到新文件。
查进程实际打开的日志文件路径
运行以下命令，确认当前所有 worker 进程正在写入哪个文件：
-
先获取 Nginx master 进程 PID：
ps aux | grep nginx | grep master | awk '{print $2}' -
列出所有 worker 进程的打开文件：
lsof -p $(cat /var/run/nginx.pid) | grep 'access.log\|error.log'（注意：若使用非默认 pid 文件路径，请替换） - 正常情况：只看到
/var/log/nginx/access.log（新文件）；异常情况：仍看到旧文件名（如access.log.20260729或已被 mv 的原始名），说明部分 worker 没 reopen 成功
验证 USR1 信号是否真正生效
发完 kill -USR1 $PID 后，不能只等几秒就执行 mv。要确认所有 worker 已完成日志 reopen：
- 用
lsof -p $PID | grep access.log | wc -l轮询检查：初始可能显示 2（旧+新），稳定后应为 1（仅新） - 配合
nginx -t确保配置无误，再nginx -s reload会重置整个进程模型，但日常切割不应依赖 reload - 如果长时间卡在 >1，说明有 worker 卡住（常见于高并发下内核调度延迟或日志写入阻塞）
检查日志文件 inode 是否变化
即使文件名被 mv，只要 inode 不变，worker 仍在往同一块磁盘空间写：
- 切割前执行：
ls -i /var/log/nginx/access.log记下 inode 号 - 切割脚本执行 mv 后，再执行：
ls -i /var/log/nginx/access.log.20260729 - 若两者 inode 相同，说明 worker 仍在写这个文件——它没 reopen，只是你重命名了它
- 此时若 gzip 或 rm 该文件，空间不会立即释放，直到所有持有该 inode 的 worker 关闭 fd
观察磁盘空间释放是否延迟
这是“未 reopen”的典型副作用：
- 执行
du -sh /var/log/nginx/access.log.20260729和df -h对比 - 如果
du显示文件体积持续增长，但df显示磁盘空间没释放，说明该文件虽被重命名，仍在被写入且未关闭 - 用
lsof +L1可直接列出被删除但仍未释放空间的文件（deleted 字样），常出现在误删旧日志后
