Linux lsof 显示 deleted 文件时如何找出占用进程

删除日志文件后，df -h 仍然显示磁盘很满，常见原因不是删除失败，而是某个进程还握着这个文件的文件描述符。用 sudo lsof -nP +L1 可以直接找出链接数已经降为 0、但仍处于打开状态的文件；输出里的 PID 和 FD 就是后续排查入口。

参考文档：https://man7.org/linux/man-pages/man8/lsof.8.html

看到 (deleted) 时，先定位持有句柄的进程，再让应用重开或关闭该句柄；不要把“目录里看不到文件”误当成“空间已经释放”。

deleted 为什么还会占用磁盘

Linux 文件名和文件内容不是同一个对象。删除操作会移除目录项；只要进程仍持有打开的文件描述符，内核中的 inode 和数据块就不会立即回收。因此目录查询看不到文件，df 却仍显示空间被占用。

lsof 会在文件名后标出 (deleted)，FD 列还可能显示 DEL。这说明文件的原路径已经失效，但打开它的进程仍然存在。配图中的“目录项”和“进程句柄”是两个边界，理解这一点比反复执行 rm 更重要。

用 lsof 找出 PID、FD 和占用大小

先执行下面的筛选命令。-nP 避免名称和端口解析带来等待，+L1 选择链接数小于 1 的打开文件。

# 只列出链接数小于 1 的打开文件，避免主机名和端口反查
sudo lsof -nP +L1

# 已知日志目录时再收窄输出，grep 只做文本筛选
sudo lsof -nP +L1 | grep -E '/var/log|deleted'

示例输出可以按下面的方式读：

COMMAND   PID  USER  FD  TYPE DEVICE SIZE/OFF   NODE NAME
worker   2468  app   7w  REG  253,0  8388608  91234 /var/log/worker.log (deleted)

这里真正有用的是 PID=2468、FD=7w 和 SIZE/OFF=8388608。7w 表示进程以写方式打开文件；大小较大时，空间压力通常就来自这一类句柄。

用 /proc 复核这个句柄是不是目标文件

拿到 PID 和 FD 后，不要只凭一行输出就重启服务。先查看进程的文件描述符链接，并读取 fdinfo 中的 inode 等信息。

# 替换为 lsof 输出中的 PID 和 FD，读取句柄当前指向
PID=2468
FD=7
sudo readlink "/proc/$PID/fd/$FD"

# 查看位置、打开标志、挂载点和 inode 等元数据
sudo sed -n '1,20p' "/proc/$PID/fdinfo/$FD"

若链接目标仍以 (deleted) 结尾，且 fdinfo 的 inode 与 lsof 行一致，就可以确认是同一个对象。权限不足时，lsof 或 /proc 可能只显示部分信息；容器和 PID namespace 中还要在拥有该进程视图的环境里检查。

另一个边界是进程可能刚好退出。PID 会被复用，所以复查时要同时看 readlink /proc/PID/exe 或命令行，不要把旧 PID 当成当前服务。

怎么释放空间才不会误伤服务

最稳妥的顺序是“让应用自己重开日志”>“受控重启服务”>“最后才考虑人工终止”。例如支持日志重开信号的服务，可以先执行服务文档规定的 reload/reopen 操作；如果应用没有这个能力，就在低峰期重启，并在重启后再次运行 lsof -nP +L1。

不要把 /proc/PID/fd/FD 当成普通文件随意覆盖，也不要仅凭文件大小就执行 kill -9。直接截断可能破坏正在写入的日志语义，强杀则可能丢失缓冲数据。处理完成后，分别用 df -h 看文件系统空间，用 lsof -nP +L1 看是否还有残留句柄。

常见问题

为什么 rm 后 du 变小，df 却不变？

du 统计目录中还能遍历到的文件，df 统计文件系统已分配的数据块；被进程打开的 deleted 文件正好会造成两者差异。

lsof 的 FD 列出现 DEL 就一定是日志吗？

不一定，也可能是共享库映射或其他已删除对象。先看 TYPE、NAME、PID 和 FD，再决定是否关联日志轮转。

重启后空间仍未释放怎么办？

重新执行筛选命令确认是否还有其他 PID/FD，尤其检查不同容器或挂载 namespace；不要假设一次重启覆盖了全部占用者。