Linux 文件删除后磁盘空间没回来：lsof deleted、进程重启与核对顺序

Linux 上删掉一个几 GB 的日志文件，df -h 却几乎没有变化，最常见的原因不是删除失败，而是某个进程还握着这个文件的文件描述符。目录里已经找不到文件名，但内核仍要等最后一个引用关闭后才能回收空间。

先判断：空间真的被已删除文件占着吗

先固定问题发生的文件系统，不要一上来就在整个根目录里反复扫描。假设告警指向 /var：

df -h /var
sudo du -xhd1 /var 2>/dev/null | sort -h
sudo lsof -nP +L1

df 反映文件系统已经分配出去的块，du 只能沿着当前目录树找到仍有路径的文件。如果 df 显示使用率很高，而 du -x 的合计明显对不上，第三条命令就是重点。

这里的 +L1 不是按文件大小过滤，而是按链接数过滤。输出中的 (deleted) 只说明路径名已经从目录中消失，不能单独证明它就在目标挂载点；还要核对设备或路径。

用 PID、FD 和挂载点锁定真正的占用者

一行结果通常包含进程名、PID、用户、FD、文件类型、设备、大小和名称。重点看三列：

拿到 PID 和 FD 后，再看内核暴露的描述符链接：

sudo ls -l /proc//fd/
sudo readlink /proc//fd/
sudo ps -o pid,ppid,user,cmd -p 

如果 readlink 仍显示类似 app.log (deleted)，并且设备与 /var 的文件系统一致，证据链就闭合了。若只有匿名内存文件、socket 或别的挂载点，不要把它当成这次磁盘告警的根因。

为什么删除了，空间还要等进程关闭

Linux 的文件名只是目录项，进程打开文件后持有的是内核文件对象。删除动作先移除目录项；只要仍有打开描述符，文件内容就不能马上回收。于是你在目录中看不到它，du 也统计不到它，但文件系统的已用块仍然存在。

这也解释了一个容易误判的现象：把服务重启后空间突然回来，并不是重启命令“删除了更多文件”，而是旧进程退出时关闭了最后一个描述符。若服务有优雅重载能力，优先让它重新打开日志；如果只能重启，先确认它由哪个管理单元托管、是否有副本和可接受的短暂中断。

按风险从低到高释放空间

先让日志组件重新打开文件

如果问题来自日志轮转，先查应用或日志组件的官方重载方式，再观察 lsof 中的旧 FD 是否消失。不要只盯着新文件名，旧文件对应的 PID 和 FD 必须真正关闭。

确认服务后再做受控重启

记录 PID、文件大小、服务名和当前告警。确认新实例会继承正确配置、日志目录可写、启动检查可执行，再重启持有者。重启后重新执行：

df -h /var
sudo lsof -nP +L1
sudo du -xhd1 /var 2>/dev/null | sort -h

如果 lsof +L1 仍有结果，可能还有旧 worker、子进程或另一个挂载点的文件没有关闭，不能以“主进程已重启”作为结束条件。

直接处理描述符只作为最后手段

向 /proc//fd/ 写入或截断，可能破坏正在写入的日志、队列文件或业务数据。除非已经确认它只是可丢弃的日志、拥有可恢复副本并经过变更审批，否则不要把这类操作当作通用清理命令。

把排查做成一次可复核的运维动作

建议把以下证据留在工单里：告警挂载点、处理前后的 df、du 汇总、lsof +L1 结果、PID/FD 对应的服务、采取的重载或重启动作，以及处理后的服务日志。这样可以区分“空间释放了”和“服务看起来还活着”这两个不同结论。

如果同一服务反复出现，重点回到轮转配置和文件打开方式：应用是否支持重新打开日志，轮转程序是否在重命名后通知了应用，是否有 worker 长时间继承旧描述符。只增加磁盘容量会暂时推迟告警，却不会改变根因。

相关问题

为什么 du 查不到，但 df 还是很高？

常见原因就是文件名已删除但仍被进程打开；也要排除挂载点选错、隐藏挂载和文件系统保留空间。

lsof 没有输出是否代表没有问题？

不一定。确认以有权限的用户运行，并把检查范围限定到正确的主机、挂载点和时间窗口；还要检查容器或独立命名空间里的进程。

重启后空间没有立即恢复怎么办？

重新执行 df 并检查是否还有旧 worker、映射文件或其他挂载点的打开引用；不要只看服务状态为 active。

总结

删除文件名和释放文件内容是两个不同动作。遇到 df 与 du 对不上时，先用 lsof -nP +L1 找到 PID/FD，再核对挂载点、服务边界和可恢复性，最后用同一组命令复查。这个顺序能避免为了追空间告警而误伤仍在工作的进程。