logging - “tail -f” 使磁盘已满？

Question

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

Answer 1

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

tail -f例如，跟随文件的活动。

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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