Linux lsof发现被删除但仍占用的日志文件

Linux 上日志文件被删除后，磁盘空间不一定立刻回来：只要进程还持有打开的文件描述符，内核就会继续保留对应 inode 和数据块。排查这类“ls 看不见、磁盘却没释放”的问题，先用 lsof +L1 找到链接数为 0 的打开文件，再按 PID 判断服务能否重载或重启。

先用 lsof +L1 找到真正占空间的对象

普通的 rm 只会移除目录项。对于仍在使用的文件，进程的打开引用还在，所以 du 按目录遍历时看不到它，文件系统却仍然计算其空间。lsof 的 +L1 会筛选 link count 小于 1 的打开文件，正好对应这类已解除链接的对象。

# -nP 禁止名称和端口解析，让排查更快且保留数字信息
sudo lsof -nP +L1

# 只观察日志所在挂载点，避免把其他文件系统混进来
sudo lsof -nP -a +L1 /var/log

重点记录 COMMAND、PID、FD、SIZE/OFF、NLINK 和 NAME。NLINK 为 0 是关键证据；NAME 可能只显示挂载点或带有 (deleted)，不要把显示路径当成仍可通过目录打开的文件。

从 PID 和 FD 复核进程仍持有的日志句柄

拿到 PID 和 FD 后，不要马上结束进程。先查看进程的描述符目录，确认它确实指向已删除的日志，并判断标准输出、错误输出或业务日志是哪一种。

# 把 1234 和 7 替换成 lsof 输出里的真实 PID、FD
pid=1234
fd=7

# readlink 只读取句柄目标，不会重新打开或修改日志
readlink "/proc/$pid/fd/$fd"

# 汇总同一进程当前持有的已删除文件
sudo ls -l "/proc/$pid/fd" | grep '(deleted)'

/proc/PID/fd/ 中每个数字项都是进程打开的描述符。若目标是普通文件且标记为 (deleted)，空间会在描述符关闭后才可回收；如果它属于管道、socket 或特殊设备，不要按日志文件的方式处理。权限不足时，使用 sudo 读取目标即可，不能据此推断服务异常。

按服务能力选择重载、重启或 copytruncate

最稳妥的释放动作是让日志程序重新打开目标路径。支持信号重载的服务可以先查它的 unit 或官方运行手册，再执行相应的 reload；如果服务没有可靠的重开日志机制，安排短暂重启通常比手工操作 /proc 句柄更可控。

# 先查看服务是否声明了可用的重载动作，再决定是否执行
sudo systemctl cat example.service

# 仅示例：确认维护窗口后再让服务重新读取日志配置
sudo systemctl reload example.service

# 没有可靠 reload 时，使用受控重启释放旧文件描述符
sudo systemctl restart example.service

不要直接对 /proc/PID/fd/FD 做写入或删除，也不要仅凭“(deleted)”就向生产进程发送强制信号。若应用无法关闭日志、又必须保持进程运行，可考虑 logrotate 的 copytruncate：它保留原文件对象并原地截断，但复制与截断之间存在很小的数据丢失窗口，需结合日志完整性要求决定。

确认空间回收并修正下一次轮转策略

动作完成后重新运行 lsof -nP +L1，确认目标 PID 和 FD 已消失，再用文件系统维度的空间统计复核。若只重命名日志而应用仍写旧句柄，下一次轮转还会重复制造隐藏占用。

排查闭环可以压缩为：lsof +L1 找对象，/proc/PID/fd/ 复核句柄，按服务能力选择动作，最后再次确认句柄和空间都已释放。

常见问题

为什么 du 看不到，但 df 仍然很高？

du 依赖目录树，已删除文件不再有目录项；df 统计文件系统已分配的块，所以仍会包含被打开的 inode。

lsof +L1 没有结果就代表没有问题吗？

不一定。它主要发现链接数为 0 的本地打开文件；还要结合挂载点、权限、NFS 行为以及其他类型的空间消耗继续判断。