在服务器运维过程中，磁盘空间不足是一个常见问题。而有时候，即使清理了大量文件，系统仍然报告磁盘几乎已满，这种情况尤为令人困惑。本文将通过一个实际案例，分享如何排查和解决Linux服务器上的"幽灵文件"——那些已被删除但仍占用空间的文件问题。

问题现象

服务器磁盘空间接近用尽，df -h命令显示根分区已使用99%：

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   37G  554M  99% /

但是使用du -h --max-depth=1 /命令检查各目录大小时，却发现所有文件夹加起来只有8.6GB：

8.6G    /
3.3G    /usr
2.8G    /var
1.1G    /etc
681M    /root
...

这里出现了一个明显的矛盾：磁盘使用报告显示已使用37GB，但实际可见文件只有8.6GB。差距在哪里？

排查流程

1. 检查Docker空间使用情况

首先怀疑是Docker容器和镜像占用了大量空间：

docker system df

结果显示Docker只使用了极少的空间：

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          3         2         378.2MB   106.6MB (28%)
Containers      2         1         0B        0B
Local Volumes   4         1         169MB     343.9kB (0%)
Build Cache     0         0         0B        0B

2. 检查日志文件

接下来检查系统日志目录：

du -sh /var/log

发现日志占用了2GB空间，其中包括：

2.0G    /var/log
1.1G    /var/log/journal
313M    /var/log/nginx

虽然日志占用了一定空间，但仍无法解释37GB的差距。

3. 搜索大文件

查找系统中超过100MB的文件：

find / -type f -size +100M -exec ls -lh {} \; | sort -rh | head -20

发现几个大文件，包括系统日志和Java应用JAR包：

-rw------- 1 root root 108M May 17 05:00 /var/log/messages.20250517050001
-rw-r--r-- 1 root root 121M May  9 15:44 /root/sgsc/java/jjj-multi-shop-2.3.jar

但这些文件总大小仍然无法解释37GB的使用量。

4. 查找已删除但仍被占用的文件

终于，使用以下命令找到了问题所在：

lsof | grep deleted | grep -v " 0r" | grep -v " 1w" | grep -v " 2w" | awk '{print $7,$9}' | sort -nr | head -20

结果显示：

10494371 /root/sgsc/java/logs/log/spring-boot-jjj-2024-09-24.11.log
10486007 /root/sgsc/java/logs/log/spring-boot-jjj-error-2024-09-24.1.log
2909327 /root/sgsc/java/logs/spring-boot-jjj-error.log

这里的数字是文件大小（KB），显示有三个已删除的日志文件分别占用了约10GB、10GB和3GB空间，总计约23GB！

发现问题根源

通过ps aux | grep java命令，发现服务器上运行着多个Java应用程序实例：

root     10569  4.0 36.4 6251020 2816296 ?     Sl   May09 467:36 java -Xms2048m -Xmx2048m ...
root     15462  0.0  7.9 4752644 615444 ?      Sl   May09  10:03 java -Xms1024m -Xmx1024m ...
root     19617  0.1 10.6 5980072 820680 ?      Sl   Apr14  56:31 java -Xms2048m -Xmx2048m ...
root     21943  0.0 12.5 5198744 973056 ?      Sl    2024 189:14 java -Xms2048m -Xmx2048m ...

问题找到了：这些Java进程仍然持有已被删除的日志文件的文件句柄。由于文件在文件系统中已被标记为删除，du命令无法计算它们的大小，但由于进程仍在使用这些文件，磁盘空间没有被释放，df命令仍然将其计入已用空间。

解决方案

1. 重启相关Java进程

kill 10569 15462 19617 21943

# 如果进程不响应，使用强制终止
# kill -9 10569 15462 19617 21943

2. 检查磁盘空间是否释放

df -h

重启进程后，磁盘使用量应该会大幅下降。

3. 重新启动应用程序

使用正确的启动命令重启应用程序。

预防措施

为避免此类问题再次发生，建议采取以下措施：

1. 配置合理的日志轮转策略：使用logback或log4j2等日志框架的RollingFileAppender，设置合适的文件大小限制和保留策略。

2. 示例logback配置：

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>logs/app.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
        <fileNamePattern>logs/app-%d{yyyy-MM-dd}.%i.log</fileNamePattern>
        <maxFileSize>100MB</maxFileSize>
        <maxHistory>10</maxHistory>
        <totalSizeCap>1GB</totalSizeCap>
    </rollingPolicy>
</appender>

3. 定期重启应用程序：对于长期运行的Java应用，计划定期重启（如每周一次）可以释放被删除文件的句柄。

4. 监控磁盘使用情况：设置监控和告警，在磁盘使用率达到阈值（如80%）时提前预警。

5. 定期检查已删除但仍被占用的文件：

lsof | grep deleted

技术原理解析

在Linux中，当一个文件被删除时，如果仍有进程打开该文件，文件的inode会保持在磁盘上，只有当所有打开该文件的进程关闭它或终止时，空间才会被真正释放。

这种机制使得进程可以继续读写已删除的文件，对于日志轮转等操作很有用，但如果应用程序不正确处理文件句柄（例如不定期关闭和重新打开日志文件），就会导致本文描述的问题。

总结

当Linux服务器磁盘空间不足，而且df和du命令显示的使用量有很大差异时，很可能是存在已删除但仍被进程打开的文件。通过lsof | grep deleted命令可以快速识别这些"幽灵文件"，重启相关进程是解决问题的最有效方法。

长期来看，合理配置应用程序的日志管理和定期维护是预防此类问题的关键。理解Linux文件系统的工作原理，可以帮助我们更有效地排查和解决服务器运维中的各种挑战。

本文基于真实服务器运维案例，希望能帮助更多遇到类似问题的技术人员快速定位和解决问题。