lsof +L1 | grep app.log kill -USR1 <pid> df -h /var/log
运维手工删了 8G 的 app.log，df 显示分区仍然 100%，lsof 里三个 java 进程还开着这个已删除的文件。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：进程持有文件描述符，文件被删除后 inode 还在，空间不会释放。日志框架没有监听文件变化，继续往旧 inode 写。
围绕「日志句柄未释放」排查时，命令行跑一遍比在面板里点十次有用，面板会替你做掉不少隐式操作。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。改完隔一天再看一次，当场正常不代表能稳住。
测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。
处理上按这个顺序：先用 lsof 找到持有已删除文件的进程；给进程发信号让它重新打开日志文件；logrotate 配 copytruncate 或 postrotate 发信号；确认 df 空间回落再清理其他文件。
确认没问题再收工，df 的已用空间回落到 60% 以下 新日志写进新建的文件。