我遇到一个问题，系统在遇到以下错误后重新启动，并且重新启动后使用率降至 75%。
dfmon[16139]：严重：磁盘可用监视器：102 #文件系统“/”已 100% 已满。
有什么方法可以从任何日志或其他地方找到占用此空间的文件吗？也许任何进程正在创建这些文件，我需要对其进行故障排除。
任何帮助深表感谢。
答案1
如果您在 /tmp 或其他可能在启动时被清空的目录中没有看到可疑的大文件，可能的原因是未链接但仍然打开文件。
这通常是由某些程序故意引起的，例如创建可以传递给其他进程但不相关进程通过文件名访问的共享内存。如果例如日志文件被轮换/删除但日志记录进程保持文件打开，则也可能无意中发生这种情况。
当所有保持文件打开的进程死亡时（因此最晚在彻底关闭系统时）以及例如fsck在电源故障后运行时，这些文件将不再存在。因此，此类文件可以解释重新启动后使用率下降。
尝试此操作（以 root 身份）查看在挂载点上创建的所有已删除但仍打开的文件/：
lsof -s -- / | grep -e '^COMMAND \| (deleted)' | less
该列COMMAND包含保持文件打开的进程的名称、SIZE文件大小（以字节为单位）以及NAME文件在删除之前的原始路径。
如果您在列表中看到一个非常大的文件或典型的日志文件名，那么您可能找到了罪魁祸首。
答案2
尝试以下操作。由于您的驱动器已满，因此可能需要一段时间。它检查根目录下的所有文件，然后按大小排序。
du / | sort -n
如果需要很长时间，那么只需获取摘要并重复，直到可以深入了解为止。
du -s /* | sort -n
答案3
包管理器通常有一个缓存，需要一些空间。sudo yum clean all或者sudo apt-get clean all可以清理一些东西。
du是一个很棒的工具。我会用du -xhd1 /
-x, --one-file-system -h, --human-readable -d, --max-depth=N
不过，不要疯狂地删除东西。我会找到您的服务器应用程序将数据写入的位置，并确保其日志不会失控