根本原因是应用进程仍持有已删除日志文件的句柄，导致磁盘空间未释放；需用lsof +l1确认被删但仍在使用的文件，再通过kill -usr1等信号让进程主动重开日志文件。
这个问题很常见：logrotate 执行完轮转，旧日志被重命名、新日志已创建，但磁盘空间没立刻释放——根本原因不是 logrotate 没干活，而是应用进程还拿着旧文件的句柄（open file descriptor），哪怕它已被 unlink，空间就卡住了。
确认是不是句柄没释放
别急着改配置或重启服务，先验证问题根源：
- 运行 lsof +L1 /var/log（或你日志所在目录），如果有输出，说明存在“已删除但仍在使用”的文件
- 更精准一点：用 lsof -nP +D /var/log | grep deleted，直接筛出被删却仍被打开的文件
- 重点看 PID 和文件路径，比如看到
/var/log/nginx/access.log (deleted)，就锁定是 nginx 进程在 hold 句柄
让进程主动释放句柄（不重启）
大多数主流服务支持信号触发日志 reopen，让进程关闭旧句柄、打开新文件：
- Nginx：执行 kill -USR1 $(cat /var/run/nginx.pid)，它会重新打开 access.log 和 error.log
- Rsyslog：用 kill -HUP $(pidof rsyslogd)
- Systemd-journald：一般不需要手动干预，但可运行 systemctl kill --signal=SIGUSR1 systemd-journald
- Java 应用（如 Log4j2）：若启用了
reconfigureOnRefresh，只需 touch 日志配置文件即可触发重载
确保 logrotate 配置正确触发信号
光靠手动发信号治标不治本，关键在 postrotate 脚本是否生效：
- 检查 /etc/logrotate.d/nginx（或其他服务配置）里是否有完整的
postrotate ... endscript块 - 典型写法：
postrotate\n if [ -f /var/run/nginx.pid ]; then\n kill -USR1 $(cat /var/run/nginx.pid)\n fi\nendscript - 注意权限：脚本中调用的命令（如 kill）必须对 logrotate 运行用户（通常是 root）可用；避免硬编码 PID 文件路径错误
- 测试配置：运行 sudo logrotate -d /etc/logrotate.conf 看模拟输出里是否执行了 postrotate 命令
预防下次再卡住
长期稳定运行，得从机制上堵住漏洞：
- 禁用“无限追加”模式：所有应用日志必须走轮转，不能直接往一个大文件里狂写
- 容器场景特别注意：给容器加 --log-opt max-size=10m --log-opt max-file=3，避免 Docker 自身日志失控
- 定期巡检：写个简单脚本每周跑一次
lsof +L1 /var/log 2>/dev/null | wc -l，结果非零就告警 - 日志路径统一管理：避免多个服务共用同一目录又没隔离，减少句柄交叉干扰
