“tail -f” 使磁盘已满？

Question

我们的应用程序服务器 (sunOS) 总是磁盘已满。我们的基础架构团队说这是由太多的“tail -f”进程引起的。因为app频繁轮转日志文件，导致死链接，没有磁盘空间？ 我以前从未听说过这个。该命令真的会导致磁盘满吗？

Answer 1

在对该文件的所有引用都消失之前，无法回收文件占用的空间。因此，任何打开该文件的进程都会阻止该文件从磁盘中删除。

例如，文件后面的活动tail -f。

如果这些文件需要被删除以释放磁盘空间（例如，因为它们非常大，或者它们数量很多），那么拥有对它们的引用的进程将阻止他们的删除，并最终导致磁盘填满。

编辑以回应对另一个答案的评论：

您报告的诊断结果正是您在 Adam 和我所描述的情况下所期望看到的。 df 报告56G 的磁盘正在使用中，du 报告只有10G 在文件夹中可见。差异是因为有 46G 价值的文件已从文件夹中删除，但由于某些进程持有对它们的引用，因此无法从磁盘中物理删除。

自己进行试验很容易：找到一个可以安全使用的文件系统，然后创建一个巨大的文件。编写一个打开文件并进入无限循环的 C 程序。现在，执行以下操作：

• 启动程序
• 检查df的输出
• rm文件
• 再次检查df的输出
• 停止你的程序
• 再次检查df的输出

您会看到df 的输出在rm 处理文件后不会改变，但在您停止程序后会改变（从而删除对文件的最后引用）。

如果您需要更多证据来证明这是怎么回事，您可以从/proc 文件系统获取信息（如果有的话）。具体来说，找到tail -f 进程之一（或您认为可能是原因的其他进程）的PID，并查看目录/proc/<pid>/fd 以查看它打开的所有文件。

（我家里没有 *nix，所以我实际上无法查看在这种情况下你会看到 /proc/<pid>/fd 的内容）

Answer 2

tail 是查看文件结尾的命令，-f 实时执行该命令，并在文件本身被修改时更新显示。它允许实时查看日志文件。

tail 可以通过两种方式引起问题：

1. 如果 tail -f 被滥用于写入文件而不是交互式控制台，则复制文件的效率很低，并且会创建重复的日志。
2. tail -f 使日志文件保持活动状态，因此尝试自动删除日志文件的维护任务失败。这会通过不允许旧日志文件老化来取消日志文件轮换。

如果您的基础架构团队抱怨访问不到一周的文件，您真的需要更多的驱动器空间和/或不太详细的日志记录策略，因为他们无法保留足够的日志以防万一出现问题并需要跟踪。如果日志比这更旧，它们可能有一个好处，并且过度使用tail（就像其他任何保持文件打开状态一样）可能会阻止它被及时删除。

该命令本身不太可能填充磁盘，但它可能会阻止磁盘清洁操作。