Nginx作为反向代理和Web服务器，日志功能是其运行状态的重要记录手段。但在长期运行过程中，如果访问日志或错误日志的文件句柄没有被正确关闭或重新打开，就可能出现句柄泄露。最直接的后果是进程可用的文件描述符逐渐耗尽，最终导致无法接受新连接，同时日志轮转后磁盘空间无法释放。下面结合具体命令和系统调用，说明如何检测Nginx日志句柄泄露并定位问题根源。
一、句柄泄露的典型表现与成因
在Linux系统中，文件句柄通常指文件描述符，也就是进程打开文件后获得的整数编号。Nginx的master进程在启动时会打开访问日志和错误日志，随后通过fork机制将句柄传递给所有worker进程。正常情况下，这些日志文件描述符会一直保持打开状态，以便不断追加写入。但当日志轮转发生时，情况就会变得复杂：logrotate等工具通常会重命名旧日志文件并创建新文件，然后通过向Nginx主进程发送USR1信号来通知其重新打开日志。如果这个信号没有正确送达，或者postrotate脚本配置有误，worker进程就会继续持有已经重命名的旧文件句柄。
这种状态下，新创建的日志文件不会被写入，而旧文件虽然已经不在原目录中，但由于仍被进程打开，其inode和磁盘空间不会被释放。从进程角度看，文件描述符数量会随着每次轮转操作而增加，如果轮转频繁，很快就能达到系统的ulimit -n限制，导致Nginx报出“Too many open files”错误。同时，通过df命令查看磁盘使用时，也会发现日志所在分区空间没有因为轮转压缩而下降，这就是典型的句柄泄露表现。
# 典型的logrotate配置，postrotate中必须发送USR1信号
/var/log/nginx/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 640 nginx adm
sharedscripts
postrotate
[ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
endscript
}
上面的配置片段中，postrotate和endscript之间的命令会在日志轮转完成后执行。如果nginx.pid文件路径不正确，或者运行logrotate的用户没有权限向Nginx主进程发送信号，那么kill -USR1就会失败，worker进程自然无法重新打开日志文件，句柄泄露便由此产生。
二、使用lsof与/proc文件系统定位泄露句柄
要判断Nginx是否真的存在日志句柄泄露，首先需要查看进程当前打开了哪些文件，以及这些文件的状态是否正常。lsof是一个功能强大的工具，可以列出指定进程的所有打开文件描述符。结合grep过滤，可以快速找出已被删除但仍被占用的日志文件。这类文件在lsof输出中通常会带有(deleted)标记，表示目录项已经不存在，但inode仍被进程引用。
除了lsof，/proc文件系统也提供了观察句柄状态的直接入口。每个进程在/proc/<pid>/fd目录下都会有一系列符号链接，每个链接指向该进程打开的文件。如果文件已被删除，链接目标末尾会追加(deleted)字样。通过ls -l列出这些链接，可以直观地看到哪些文件描述符指向了已经消失的日志文件。此外，还可以统计当前打开的句柄总数，与系统限制进行对比，从而评估泄露的严重程度。
# 查找Nginx worker进程打开的deleted文件和日志文件 lsof -p $(pgrep -f "nginx: worker" | head -1) | grep -E "deleted|access.log|error.log" # 通过/proc文件系统查看句柄状态 ls -l /proc/$(pgrep -f "nginx: worker" | head -1)/fd | grep -E "deleted|access.log|error.log" # 统计当前打开的文件描述符总数 ls /proc/$(pgrep -f "nginx: worker" | head -1)/fd | wc -l
如果上述命令的输出中出现了大量指向/var/log/nginx/access.log.1 (deleted)这样的行，就说明日志句柄泄露确实存在。此时即使磁盘上已经没有了access.log.1这个文件名，Nginx仍会继续向这个已删除的inode写入数据，而新创建的access.log则完全得不到任何日志内容。同时，随着轮转次数增加，deleted句柄的数量会线性增长，最终可能耗尽所有可用文件描述符。
三、结合strace追踪日志写入与关闭行为
strace可以跟踪进程的系统调用，帮助我们从底层确认句柄泄露的具体环节。通过附加到正在运行的Nginx worker进程，可以记录open、openat、close以及write等与文件操作相关的调用。如果发现进程在日志轮转后执行了openat打开新日志文件，却没有调用close关闭旧文件描述符，那么就可以断定是关闭逻辑缺失导致的泄露。对于已经持有旧句柄的进程，每次重新打开日志都会增加一个新的文件描述符，而旧句柄永远不会被主动释放。
在实际操作中，由于strace会对进程性能产生一定影响，建议在生产环境只进行短时间跟踪，或者先在测试环境复现问题。可以使用-f参数跟踪线程和子进程，并使用-o将输出保存到文件，避免影响终端。跟踪结束后，再通过grep筛选与日志文件相关的调用记录，重点观察openat返回值中的文件描述符编号是否持续递增且没有对应的close调用。
# 短时间跟踪Nginx worker进程的系统调用 strace -f -e trace=open,openat,close,write -p $(pgrep -f "nginx: worker" | head -1) -o /tmp/nginx_strace.log & sleep 30 kill %1 # 查看与日志文件相关的调用记录 grep -E "access.log|error.log" /tmp/nginx_strace.log | tail -100
从输出中可以观察到类似openat(AT_FDCWD, "/var/log/nginx/access.log", O_WRONLY|O_APPEND) = 10的记录，如果后续很长时间内都没有出现close(10)，而新的openat又返回了11、12等更大的描述符编号，就表明句柄正在不断累积。当然，Nginx worker进程本身会保持日志文件长期打开，这是正常行为，关键要看轮转前后的描述符变化。可以手动触发一次nginx -s reopen，然后观察旧描述符是否被关闭，如果旧描述符仍然存在，则泄露原因与信号处理或代码逻辑有关。
四、修复方案与预防措施
修复日志句柄泄露的第一步是检查logrotate配置中postrotate部分是否真正生效。可以手动执行nginx -s reopen命令，观察日志文件是否重新打开，以及lsof中是否出现新的日志句柄而旧句柄被关闭。如果手动执行成功，但logrotate轮转后仍然泄露，则问题很可能出在nginx.pid路径不正确，或者logrotate运行权限不足。此时需要调整配置文件，使用绝对路径指定PID文件，并确保执行logrotate的用户（通常是root）有权限发送信号。
对于容器化部署的Nginx，情况可能更加复杂。容器内/var/run/nginx.pid的路径可能被自定义，或者容器重启后PID文件残留导致误判。建议在容器环境中使用nginx -s reopen结合kill -USR1进行测试，并确认日志文件挂载方式是否正确。同时，可以在Nginx配置中适当调高worker_rlimit_nofile的值，以增加文件描述符上限，但这只能缓解问题，不能替代真正修复。最根本的做法是保证每次日志轮转后，所有worker进程都能通过信号重新打开日志文件。
#!/bin/bash
# 定期检查Nginx文件描述符数量和deleted句柄数量
PID=$(pgrep -f "nginx: master" | head -1)
if [ -z "$PID" ]; then
echo "Nginx master process not found"
exit 1
fi
FD_COUNT=$(ls /proc/$PID/fd | wc -l)
DELETED_COUNT=$(ls -l /proc/$PID/fd 2>/dev/null | grep -c deleted)
echo "Nginx master PID: $PID"
echo "FD count: $FD_COUNT"
echo "Deleted fd count: $DELETED_COUNT"
if [ "$FD_COUNT" -gt 1000 ]; then
echo "Warning: too many file descriptors, possible handle leak"
fi
预防方面，可以部署监控脚本定期统计Nginx进程的句柄总数和deleted句柄数量，当数值异常增长时发出告警。同时，在日志轮转配置中增加必要的校验逻辑，确保信号发送成功，例如在postrotate脚本末尾检查kill命令的返回值。如果条件允许，也可以将Nginx日志交给systemd-journald或rsyslog等集中式日志系统处理，从而减少本地文件句柄管理的复杂度。这些措施结合起来，能够有效避免因日志句柄泄露导致的线上故障。