nginx高并发日志切割易因usr1信号竞争导致文件句柄死锁，需通过轮询lsof确认fd释放、flock加锁防并发、stat校验空日志三重保险规避；替代方案可用systemd logrotate的copytruncate模式实现零中断。
高并发场景下，Nginx 日志切割脚本若设计不当，极易引发文件句柄死锁——表现为新日志写不进、旧日志删不掉、磁盘空间不释放、甚至 worker 进程卡住无响应。根本原因不是脚本没跑，而是信号时机、进程状态和内核文件描述符（fd）管理之间出现了竞争。下面直击关键点，给出可落地的规避策略。
为什么 USR1 信号在高并发时可能失效
Nginx Master 收到 kill -USR1 后，会逐个通知所有 Worker 重新打开日志文件。但在每秒数万请求的峰值期：
- Worker 正在密集写日志，内核调度延迟可能导致部分进程迟迟未执行 reopen 操作；
- 若此时脚本已
mv旧日志，而某个 Worker 仍持有原 fd，它会继续往已被重命名的文件写入（看似“消失”的日志其实还在增长）； - 更危险的是：若脚本紧接着
gzip或rm该重命名后的文件，Linux 会推迟释放磁盘空间，直到所有持有该 fd 的进程真正关闭它——而这可能卡住几秒甚至更久。
切割脚本必须加的三道保险
单靠 mv + kill -USR1 不够。需叠加状态校验与容错机制：
-
等信号落地再操作：发完 USR1 后，用
sleep 0.5（非必须），但更可靠的是轮询确认——检查lsof -p $PID | grep 'access.log' | wc -l是否从 2（旧+新）回落到 1（仅新）； -
避免并发切割：用文件锁（如
/tmp/nginx-logrotate.lock）配合flock，防止 cron 多次触发或手动误执行导致冲突； -
跳过空日志 & 防止误删：先
stat -c '%s' access.log判大小，若为 0 字节，直接跳过 mv 和信号步骤，避免对空文件做无意义操作。
替代方案：用 open_file_cache 配合时间戳日志名（免信号）
如果业务允许，可彻底绕开 USR1 竞争问题：
- 在
nginx.conf中将日志路径改为带时间戳的动态格式：access_log /var/log/nginx/access_$(date +%Y%m%d).log main; - 注意：Nginx 原生不支持
$(date)，需借助nginx-plus或 OpenResty 的 Lua 模块； - 更通用做法是用 systemd 的
logrotate+copytruncate模式：它先复制当前日志，再清空原文件（truncate -s 0），Nginx 无需 reopen，fd 始终有效，零中断。
线上验证是否已陷入句柄死锁
发现日志异常增长慢、磁盘空间不下降时，快速诊断：
- 查哪些进程还拿着旧日志：
lsof | grep 'access.*20260506' | awk '{print $2}' | sort -u（替换日期）； - 看对应进程是否仍在运行：
ps -p PID -o pid,comm,etime（etime显示已运行秒数，若远大于切割间隔，说明卡住）； - 强制释放（仅应急）：
kill -USR1 $MASTER_PID再等 3 秒，仍未释放则重启 Nginx（最后手段）。
