Nginx日志切割核心是重命名日志文件后发送USR1信号，因Linux通过文件描述符而非文件名写入，mv不丢日志；USR1仅重开日志文件，避免reload中断服务，需校验pid存在及权限正确。
不用 logrotate 就得自己接管日志文件句柄切换逻辑，核心是两件事：重命名日志 + 发送 USR1 信号让 Nginx 重新打开新文件。漏掉任一环节，Nginx 就继续往旧文件写，切割就失效。
为什么直接 mv 日志文件不会丢日志
Nginx 工作进程在启动时通过 open() 系统调用拿到日志文件的文件描述符（fd），后续所有写入都基于这个 fd，和文件名无关。所以你 mv /var/log/nginx/access.log /var/log/nginx/access.log-20260614 后，Nginx 仍在往那个 inode 写数据——只要没发 USR1，它根本不知道文件被改名了。
- 这是手动切割能成立的前提，不是“碰巧没丢”，而是 Linux 文件系统机制决定的
- 验证方式：切割后立刻
ls -li /var/log/nginx/，对比access.log和刚 mv 出来的文件的 inode 号，应该一致 - 如果用了
copytruncate或其他非原子操作，反而可能丢日志，不推荐
postrotate 脚本必须用 kill -USR1，不能用 systemctl reload
systemctl reload nginx 或 nginx -s reload 会触发完整配置重载，可能中断连接、清空 upstream 连接池，对高并发服务风险较大；而 kill -USR1 只让主进程通知 worker 进程关闭旧 fd、按配置重新 open 新日志文件，全程无请求中断。
- 确保 pid 文件路径正确：
/var/run/nginx.pid或/usr/local/nginx/logs/nginx.pid，取决于你的安装方式 - 脚本里要加判断：
if [ -f /var/run/nginx.pid ]; then kill -USR1 $(cat /var/run/nginx.pid); fi，避免因 pid 文件不存在导致命令失败 - 如果 Nginx 是以非 root 用户运行（如 www-data），脚本执行用户也得有权限读取该 pid 文件
定时任务要避开 logrotate 自动运行时间
默认 /etc/cron.daily/logrotate 在凌晨触发，如果你的 crontab 也设在类似时间（比如 0 0 * * *），两个任务可能并发操作同一组日志文件，造成冲突或重复切割。
- 建议错开：比如设为
15 3 * * *（每天 3:15），或用@daily加随机延迟 - 测试脚本时务必加
-v参数观察输出，例如：/opt/nginx_logrotate.sh && echo "done" || echo "fail" - 检查日志权限：新生成的
access.log默认由 Nginx worker 用户创建，但首次 touch 或 mv 后若权限不对（比如 root 创建但 nginx 用户无法写），会导致后续写入失败，错误会出现在error.log里，关键词是open() "/var/log/nginx/access.log" failed (13: Permission denied)
真正难的不是写几行 shell，而是理解 Nginx 日志写入的底层行为、信号语义和权限继承链。一个没校验 pid 文件是否存在、没确认新日志文件属主的脚本，在上线后某天磁盘告警时才会暴露问题。
