磁盘空间满导致Nginx错误日志静默停止更新，需先确认error_log真实路径及Nginx工作用户对各级目录的x/w权限，再用df -h和df -i检查磁盘块与Inode是否耗尽，通过nginx -e stderr、strace或lsof +L1定位系统层写入失败原因，并以reload或USR1信号恢复日志写入。
磁盘空间满导致 Nginx 错误日志写入失败时，error_log 往往静默停止更新，甚至完全为空——这不是配置失效，而是系统层面已无法落盘。排查关键不在日志内容本身，而在确认“Nginx 是否还尝试写、为什么写不进、卡在哪一级”。
先确认 error_log 是否真在写、写到哪了
别默认看 /var/log/nginx/error.log。打开 nginx.conf，找到 error_log 指令，确认实际路径（如 /data/logs/nginx/error.log）。常见问题是路径存在但父目录缺失或权限不对，导致 Nginx 启动时连日志模块都初始化失败。
- 运行
ps aux | grep nginx，确认 worker 进程使用的用户（如nginx或www-data） - 检查该用户对日志路径各级父目录是否有
x（进入）和w（写入）权限：ls -ld /data/logs /data/logs/nginx - 若路径含多级（如
/data/logs/nginx/a/b），每一级都必须存在且可进入（x权限不可缺）
立刻查磁盘块与 Inode 是否耗尽
磁盘满有两种典型表现：空间（block）耗尽和 Inode 耗尽，都会让 write 系统调用失败，但排查方式不同。
- 执行
df -h：看 error_log 所在分区的Use%是否为 100%，Avail是否为 0 - 执行
df -i：重点看IUse%，达 100% 表示无法创建新文件（常见于 logrotate 生成大量.log.1、.log.2.gz后未清理） - 运行
lsof +L1 | grep nginx：若有access.log (deleted)或error.log (deleted)，说明文件已被删但句柄仍被占用，磁盘空间未释放
绕过日志本身，直接看系统反馈
当 error_log 已空，就无法依赖它报错。需从系统层抓真实失败原因：
- 强制终端输出启动错误：
nginx -c /etc/nginx/nginx.conf -e stderr，可捕获“could not open error log file”等早期失败 - 跟踪 worker 写操作：
strace -p $(pgrep -f "nginx: worker") -e trace=write,openat,fsync -s 256 2>&1 | grep -E "(log|denied|No space)"，看到write返回-1 ENOSPC即确认磁盘满 - 查 SELinux/AppArmor 干预：
ausearch -m avc -ts recent | grep nginx（CentOS/RHEL）或aa-status | grep nginx（Ubuntu）
验证并恢复日志写入能力
确认是磁盘满后，不能只清日志文件，要确保 Nginx 重新获得可写句柄：
- 首选安全方式：
nginx -s reload，会优雅关闭旧 worker 日志句柄，新建日志文件，空间立即释放 - 若 reload 失效，发 USR1 信号：
kill -USR1 $(cat /usr/local/nginx/logs/nginx.pid) - 检查 logrotate 是否生效：确认配置含
create 0644 nginx nginx和postrotate ... kill -USR1 ... endscript
