磁盘明明删了文件，空间却没回来：先查被进程占着的已删除文件

磁盘告警响了，删掉几个大日志文件，df 一看，可用空间纹丝不动。这种“删了等于没删”的情况，十有八九是文件还被某个进程占着：文件在目录里已经看不见了，但进程手里还握着它的句柄，内核就不会真正回收空间。

先确认是不是这个问题。用 lsof +L1 可以列出已删除但仍被打开的文件，输出里带有 (deleted) 标记的就是嫌疑对象。同一条信息也可以从 ls -l /proc/*/fd 里看到：被删除文件的符号链接后面会跟一个 (deleted) 后缀。如果这类条目占了几个 GB，基本可以断定空间是被它们拖住的。

接下来要分两种情况处理。第一种是日志文件被删但写日志的服务还在跑，比如 nginx、某个 Java 应用。正确做法不是杀进程，而是让服务重新打开日志：对 nginx 用 nginx -s reopen，对一般服务用 systemctl reload 或发 SIGHUP，具体看服务支不支持重载。重载后旧句柄释放，空间立刻回来，服务也不用停。

第二种是删掉的文件根本不是日志，而是某个早已退出的任务留下的临时文件，却被一个长驻进程一直握着。这时先用 lsof 看清是哪个进程、哪个文件，再决定是重启该进程还是等它自己退出。不要上来就 kill -9：正在写文件的进程被强杀，数据可能只写一半；能优雅重启就优雅重启。

还有一个容易混淆的点：df 和 du 对不上不一定都是已删除文件。挂载点被文件“盖住”也会造成这种现象——比如某个目录在挂载前就被写了数据，挂载后这些数据被遮住，du 扫不到，df 却照算。怀疑是这种情况时，把可疑挂载点临时卸载再看一眼，或者用 du -x 限定在同一文件系统内统计，就能区分开。

最后是预防。日志类文件不要靠人工删：logrotate 配好按大小或时间轮转，配合 copytruncate 或服务重载，空间就不会被已删除文件拖住；临时文件写到独立目录并定期清理；磁盘告警阈值设到 80% 而不是 95%，留出处理时间。下次再遇到“删了没空间”，先跑 lsof +L1，三分钟就能知道是该重载服务，还是该重启进程，而不是对着 df 干着急。