nginx日志轮转失败主因是master未收到usr1信号，worker仍写旧fd；需确认pid路径、权限、绝对路径配置、logrotate的sharedscripts与create选项，并用nginx -s reopen替代kill -usr1。
kill -USR1 信号没发成功，Nginx 还在往旧文件描述符写
这是最常见原因：Nginx Master 进程没收到信号，所有 Worker 仍持有原 access.log 的文件描述符（fd），重命名后继续往 access_20260907.log 写——而你新建的 access.log 是空的，看起来“不写日志”。
检查点：
-
ls -l /proc/$(cat /var/run/nginx.pid)/fd/ | grep log—— 看是否还挂着旧日志路径 -
nginx -t必须通过，否则nginx -s reopen会静默失败 - PID 文件路径错：宝塔默认是
/www/server/nginx/logs/nginx.pid，systemd 启动常用/run/nginx.pid或/var/run/nginx.pid，cat前先ls确认 - 权限问题：logrotate 脚本若以普通用户运行，
kill -USR1会被拒绝，需加su nginx -c "nginx -s reopen"或用sharedscripts+create
nginx.conf 里 access_log 路径是相对路径，mv 后找不到目标位置
比如配置写的是 access_log logs/access.log;，脚本却在 /usr/local/nginx/ 下执行 mv logs/access.log ...，但 Nginx 实际工作目录可能是 / 或其他路径，导致 reopen 时创建的新文件落在意外位置（甚至被丢弃）。
务必使用绝对路径：
- 检查当前配置：
nginx -T 2>/dev/null | grep 'access_log' - 确认输出是类似
access_log /var/log/nginx/access.log main;这样的完整路径 - 脚本中所有
mv和信号操作，都基于这个绝对路径的父目录做
logrotate 配置漏了 sharedscripts 或 postrotate 执行失败
logrotate 默认对每个匹配文件单独执行 postrotate，如果同时有 access.log 和 error.log，它可能发两次 kill -USR1，中间若 Nginx 正在 reload，会导致部分 worker 未完成 reopen。
正确写法必须包含：
-
sharedscripts：确保postrotate只执行一次 -
missingok：避免某天无日志时报错退出，后续轮转全停 -
create 0644 nginx nginx：保证新日志可写（尤其当 Nginx 以非 root 用户运行时） -
postrotate内部用nginx -s reopen比kill -USR1更健壮，它自带校验逻辑
切割脚本执行时 Nginx 正在 reload 或升级，USR1 被忽略
USR1 不是原子信号。如果脚本运行期间 Nginx 正在执行 nginx -s reload（比如因配置变更自动触发），Master 进程会忙于 fork 新 worker、关闭旧 worker，此时 USR1 可能被丢弃或延迟处理，造成 fd 切换卡住。
缓解方式：
- 避开业务高峰时段执行切割（如凌晨 00:05 而非整点）
- 脚本中加简单等待：
sleep 1再发信号，给 reload 留出窗口 - 用
lsof -p $(cat /var/run/nginx.pid) | grep 'access.log' | wc -l检查是否已切换为 1 个 fd（新文件），否则重试最多 2 次
真正麻烦的不是“怎么切”，而是“怎么确认切干净了”。只要有一个 worker 还拿着旧 fd，磁盘空间就不会释放，新日志就始终为空——这点容易被忽略，但线上一卡就是几小时。
