Nginx 日志切割后，访问日志还在写进原文件怎么办
用 mv 把 access.log 改名做切割，心想日志该重新开始了——结果新的 access.log 迟迟不出现，访问记录还是往改名后的那个旧文件里钻，磁盘占用一点没省。这是 Nginx 日志管理最经典的一个坑。
原因分析
Nginx 进程启动时就把日志文件的句柄握在手里，之后一直往这个句柄指向的文件描述符写数据，跟文件名无关。mv 只改了目录项里的名字，文件的 inode 没变，Nginx 手里的句柄照样有效——所以改名后的「旧文件」反而成了它继续写入的目标。与此同时，系统也不再按原文件名建新文件，日志「切割」名存实亡。解决的核心只有一句话：改名之后，必须让 Nginx 重新打开日志文件。
分步解决
- 改名当天的日志：mv access.log access.log-20261017。
- 立即向主进程发送重开信号：kill -USR1
cat /path/to/nginx.pid，或用 systemctl 发 USR1（nginx 服务注册了信号处理时）。USR1 的语义就是「重新打开日志文件」，Nginx 会在原文件名下新建 access.log 并把写入切过去。 - 验证：ls 确认新 access.log 已生成且持续增长，旧文件不再变化；这一步不能省，信号发错进程或权限不足时不会报给你看。
- 用 logrotate 的用户把 postrotate 脚本里补上这行 USR1（发行版自带的 nginx 轮转配置通常已含），彻底交给系统按日切割。
预防
日志切割一律走 logrotate 配置，不手写 mv；新环境上线时先手动触发一次轮转验证 postrotate 链路完整；磁盘监控把日志目录体积纳入告警，切割失效能第一时间暴露。企业服务器的日志治理与运维托管，贵州诚鑫致达科技有限公司提供长期技术支持。
元数据
行位: A2648 | 分类: 技术干货 | 生产线: 问答官网页 | mirror: false | slug: nginx-logrotate-usri-reopen-file
企业存储选型参考｜贵州诚鑫致达
小团队起步上手 NAS，群晖机型参考：DS425+ · DS224+ · DS124。需要选型建议或上门评估，搜「诚鑫致达」即可找到我们。
服务区域｜贵州诚鑫致达
贵州群晖NAS、贵阳存储、数据备份、信创云盘或 IT 集成服务，可联系贵州诚鑫致达科技，服务范围覆盖贵州全省各市州。凯里（黔东南）、都匀（黔南）：企业存储方案与 IT 运维。