为什么nginx日志切割会失败

Nginx 本身并不自带日志自动切割功能，所谓“日志切割失败”通常是指：

• 用了 logrotate 但没生效
• 自己写脚本切割但有问题
• 切割后 Nginx 还在写旧文件
• 或权限 / 信号 / 配置不对

下面按常见原因 → 现象 → 解决办法来说明。

一、最常见原因：logrotate 没通知 Nginx 重新打开日志

现象

• 日志文件被重命名或移动了
• 但 Nginx 仍然往旧 inode写
• 磁盘空间不释放，或新日志为空

原因

Nginx 打开的是文件描述符，不是文件名
只移动文件 ≠ 让 Nginx 换文件

正确做法（关键）

必须在切割后让 Nginx 重新打开日志：

kill -USR1 `cat /var/run/nginx.pid`

或 logrotate 配置里加：

postrotate
    [ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid)
endscript

✅ 少了这一步，100% 会“看起来失败”

二、logrotate 配置写错

常见错误配置

❌ 没有 daily / size

/var/log/nginx/*.log {
    rotate 7
    missingok
}

✅ 正确示例

/var/log/nginx/*.log {
    daily
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid)
    endscript
}

三、Nginx 没权限写新日志

现象

• 切割后新日志不生成
• Nginx 报错（或无声失败）

原因

• 日志目录权限不对
• Nginx 以 www-data / nginx 运行
• root 切割后文件属主变了

检查

ls -l /var/log/nginx
ps aux | grep nginx

解决

确保：

chown -R nginx:nginx /var/log/nginx

四、用了 copytruncate 但理解错了

copytruncate 干了什么

• 复制日志
• 然后清空原文件（不清空 inode）

问题

• 可能丢日志（复制和清空之间有窗口）
• 不适合高并发写日志

建议

✅ Nginx 不建议用 copytruncate
✅ 用 mv + USR1 才是正确的

五、logrotate 根本没执行

检查是否运行

logrotate -d /etc/logrotate.d/nginx

强制执行一次：

logrotate -f /etc/logrotate.d/nginx

常见坑

• 放错目录
• 文件名不对
• cron 没开

六、Docker / K8s 环境特殊情况

现象

• 宿主机切割无效
• 容器里 Nginx 不响应信号

原因

• PID 不是 1
• 信号发错容器

正确方式

• 用 Docker log driver
• 或在容器里执行：

nginx -s reopen

七、快速自检清单 ✅

• [ ] 是否发送 USR1 信号
• [ ] logrotate 是否真的执行
• [ ] Nginx 是否有写权限
• [ ] 是否用了错误的 copytruncate
• [ ] 是否在 Docker / 容器中

如果你愿意，可以把：

• 你的 logrotate 配置
• 或 切割脚本
• 或 报错信息

发出来，我可以直接帮你定位是哪一种失败。