Linux删除文件后磁盘空间不释放？lsof排查与处理教程

清理 Linux 服务器时，有时会遇到这样的情况：几 GB 的日志文件已经删除，目录里也找不到了，但执行 df -h，磁盘使用率仍然没有明显下降。

常见原因之一是：文件名已经删除，运行中的进程仍然保持着文件的打开引用。 此时文件还在占用空间，需要相关引用释放后，空间才有机会被回收。

下面以 Linux 主机上的日志文件为例，介绍如何确认文件系统、找到占用进程，以及处理后怎样验证。

一、确认查看的是同一个文件系统

以下以根分区 / 为例：

df -hT /
df -i /
sudo du -xhd1 /

如果需要检查独立挂载的 /data 分区，将三条命令中的 / 都替换为 /data。

命令	查看内容
`df -hT`	文件系统容量、使用率、类型和挂载点
`df -i`	inode 使用情况，帮助判断是否因大量小文件耗尽 inode
`du -xhd1`	当前文件系统内，指定目录及其一级子目录的文件占用

df 统计文件系统的空间使用情况，du 则通过目录遍历统计文件占用。

文件删除后，如果进程仍保持打开引用，普通目录遍历已经找不到它，du 就不会再从原路径统计到这部分内容，而 df 仍可能显示空间被占用。

两者统计口径不同，结果不要求完全一致。 明显差异可以作为排查线索，不能仅凭差异就断定存在文件占用。

二、使用lsof查找已删除但仍被占用的文件

执行：

sudo lsof -nP +L1

其中，+L1 用于筛选链接数小于 1 的已打开文件，常用于查找删除后仍被进程引用的文件。

如果提示没有安装 lsof，可按系统安装：

# Debian / Ubuntu
sudo apt install lsof

# Rocky Linux / AlmaLinux
sudo dnf install lsof

下面是输出格式示例，PID、路径和大小仅用于说明：

COMMAND  PID USER     FD TYPE DEVICE   SIZE/OFF NLINK   NODE NAME
nginx   2317 www-data 7w REG     8,1 2147483648     0 123456 /var/log/nginx/access.log (deleted)

重点查看这些字段：

字段	含义
`COMMAND`	占用文件的进程名称
`PID`	进程编号
`TYPE`	`REG` 表示普通文件
`SIZE/OFF` 或 `SIZE`	普通文件通常显示字节大小
`NLINK`	链接数，示例中为 0
`NAME`	文件路径及删除标记

上面的记录表示：一个 Nginx 进程仍然打开着已经删除的日志文件。

同一个文件可能被多个进程或文件描述符引用。相同 DEVICE 和 NODE 的记录，不应直接重复累加大小。 文件逻辑大小也不一定等于最终能回收的磁盘空间。

另外，memfd、共享内存或其他文件系统上的记录，不一定与当前磁盘告警有关。如果出现权限或读取警告，查询结果可能不完整，需要先处理这些问题。

三、确认进程属于哪个服务

将下面的 2317 替换为实际查询到的 PID：

target_pid=2317

ps -p "$target_pid" -o pid,ppid,user,comm,args

sudo lsof -nP -a -p "$target_pid" +L1

这里的 -a 表示同时满足筛选条件，只查看该进程打开的已删除文件。

对于使用 systemd 管理服务的主机，还可以执行：

sudo systemctl status "$target_pid" --no-pager

通过输出确认它对应哪个业务服务。

如果显示的是登录会话或容器相关单元，应继续查清实际程序的管理方式，不能直接把整个会话或容器管理服务当作重启目标。

四、让对应程序释放旧日志

以下处理以确认可以丢弃的日志文件为前提。若误删的是数据库或仍需保留的业务数据，应先制定恢复方案，避免关闭进程后失去恢复机会。

Nginx：重新打开日志文件

如果确定占用的是 Nginx 日志，可以使用日志重开功能。

对于采用默认配置启动的单实例 Nginx：

sudo nginx -t && sudo nginx -s reopen

配置检查成功后，命令会通知 Nginx 主进程重新打开日志，并让工作进程关闭旧日志文件。

宝塔安装、自编译安装或多实例环境，需要使用对应实例的 Nginx 程序路径及配置参数，确保操作的是实际占用文件的实例。

执行后继续检查 lsof，确认旧日志引用是否已经释放。如果重开失败，应检查日志目录、权限和可用空间。

其他程序：按应用机制处理

先查看应用是否提供日志重开或轮转功能。不同程序对信号和 reload 的处理方式不同，不能直接套用 Nginx 的命令。

如果程序没有合适的日志重开方式，且允许短暂中断，可在确认服务名称后重启对应业务服务：

sudo systemctl restart myapp.service
sudo systemctl status myapp.service --no-pager

这里的 myapp.service 是示例名称，必须替换为实际服务。

重启会中断该服务，应提前确认配置、启动条件和业务影响。不要根据 lsof 输出批量强制结束进程。

五、验证空间和业务状态

处理后重新执行：

sudo lsof -nP +L1
df -hT /
df -i /

如果检查的是独立数据分区，仍然需要替换对应路径。

重点确认：

目标日志文件对应的占用记录是否消失。
目标文件系统的可用空间是否增加。
服务是否正常运行，网站或接口是否能访问。
新日志是否能够继续正常写入。

lsof 仍有其他记录，不代表本次处理失败，应关注之前定位到的目标文件。

六、处理后空间仍未恢复怎么办？

情况	下一步检查
目标文件仍出现在 `lsof` 中	查看是否还有其他进程持有相同文件
文件记录消失，但空间仍紧张	检查其他目录占用，以及程序是否正在快速生成新文件
清理后当前分区使用率不变	用 `df -hT` 核对被清理目录所在的文件系统
容量尚有剩余，但无法创建文件	查看 `df -i`，确认 inode 是否耗尽

释放旧日志后，还应配置日志轮转和保留周期，确保轮转时应用能正确切换到新文件。对于持续重复输出的报错，应同时排查错误来源，避免磁盘很快再次被写满。