日志磁盘写满是Nginx服务挂起最隐蔽常见原因，导致worker进程卡住、出现502/504、上传失败及tail -f无输出等假死现象；需通过df -h、lsof +L1、ps aux三步定位，用echo清空日志、kill -USR1释放句柄应急，并配置logrotate与日志降级防复发。
日志磁盘写满是 Nginx 服务挂起最隐蔽也最常见的原因——它不报错，但会让 worker 进程卡住、无法响应新请求，表现为 502/504、上传失败、tail -f 日志无输出等“假死”现象。排查核心是三步：确认磁盘是否真满、验证日志句柄是否被占用、判断进程是否已失去响应能力。
一、快速定位磁盘与日志文件异常
别直接重启，先用命令交叉验证：
- 运行 df -h，重点看 /var/log、/var/lib/nginx 或 /tmp 所在分区是否 ≥95%；
- 执行 ls -lSh /var/log/nginx/，检查 access.log 和 error.log 是否超 1GB（单个几百 MB 就需警惕）；
- 运行 lsof +L1 | grep nginx，若输出中含 access.log (deleted) 或 error.log (deleted)，说明日志已被删但进程仍持有句柄，空间未释放；
- 执行 ps aux | grep nginx，若只有 master 进程、无 worker 进程，或 worker 状态为 Z（僵尸） 或 CPU 长期为 0，基本可锁定为日志空间问题。
二、应急恢复：清空间 + 强制释放句柄
目标是让服务秒级恢复，不中断主进程：
- 清空日志内容而非删除文件：echo "" > /var/log/nginx/access.log 和 echo "" > /var/log/nginx/error.log；
- 若已误删且 lsof +L1 显示 deleted，先触发日志 reopen：kill -USR1 $(cat /var/run/nginx.pid)，再对残留句柄做 reload 或 kill -HUP 对应 worker PID；
- 更稳妥方式是 nginx -s reload（前提配置无误）；若 reload 失败或 worker 无响应，可 kill -9 所有 worker 进程（保留 master），系统会自动拉起新 worker；
- 最后再次 df -h 确认释放，并 tail -f /var/log/nginx/error.log 观察是否开始正常写入。
三、防复发：用 logrotate + 权限控制堵住漏洞
人工清理永远滞后，必须靠机制保障：
- 启用 logrotate 并配全参数：每日轮转、保留 7 天、自动压缩、跳过空文件（daily rotate 7 compress missingok notifempty）；
- 在 nginx.conf 中限制日志粒度：error_log /var/log/nginx/error.log warn;（关闭 debug/info），非核心 location 加 access_log off;；
- 设置磁盘水位告警，例如用脚本定时执行：df -h | awk '$5+0 > 85 {print $0}'，配合钉钉或邮件通知；
- 把 client_body_temp_path 等临时目录单独挂载小容量磁盘，避免日志膨胀挤占核心路径。
