「tail -f」會使磁盤滿？

我們的應用程序服務器（sunOS）總是讓磁盤滿。我們的基礎設施團隊表示這是由於太多的「尾巴」過程造成的。由於該應用程序頻繁旋轉日誌文件，導致死鏈接並且沒有磁盤空間？我從來沒有聽說過這個。該命令是否真的會導致磁盤已滿？「tail -f」會使磁盤滿？

來源

2012-03-21 user462872

這個問題可能對堆棧溢出的姐姐一個更合適網站，http://www.serverfault.com。 – 2012-03-21 06:18:13

謝謝你，亞當。讓我把它發佈到serverfault.com。順便說一下，我看到在我們退出膩子會話或按下'Ctrl + C'後尾部進程會被殺死，爲什麼有這麼多的尾部進程讀取日誌文件？ – user462872 2012-03-21 09:40:16

這是一個極好的問題。不幸的是，我不太瞭解Linux系統管理，告訴你如何跟蹤。與ServerFault的問題版本祝你好運。 – 2012-03-21 18:43:01

文件佔用的空間不能被回收，直到對該文件的所有引用都消失爲止。因此，打開該文件的任何進程都將阻止文件從磁盤中刪除。例如，

該文件之後的活動tail -f。

如果這些文件需要將刪除以釋放磁盤空間（例如，因爲它們非常大或者其中有很多），然後讓周圍的進程持有對它們的引用將阻止它們的刪除，並且最終導致磁盤填滿。

編輯迴應對對方的回答註釋：

你報告的診斷是正是你所期望的，亞當和我所描述的情況，看看有什麼。 df報告磁盤的56G正在使用中，並且du報告在文件夾中只有10G可見。這種差異是因爲有46G價值的文件已從文件夾中刪除，但無法從磁盤上物理刪除，因爲某些進程持有對它們的引用。

很容易就可以親自嘗試一下：找到一個可以安全玩的文件系統，並創建一個龐大的文件。編寫一個打開文件並進入無限循環的C程序。現在，請執行下列操作：

啓動程序
檢查的df
rm文件輸出
檢查的df輸出再次
停止程序
檢查輸出的df再

您將看到df的輸出不會在rm文件後發生變化，但在您停止程序（因此刪除最後一個對該文件的引用）後會發生變化。

如果您需要更多的證據證明這是發生了什麼，您可以從/proc文件系統獲得信息（如果有的話）。具體而言，找到tail -f進程（或其他您認爲可能是原因的進程）之一的PID，然後查看目錄/proc/<pid>/fd以查看它已打開的所有文件。

（我不在家* nix的，所以我不能真正檢查，看看正是你會看到/proc/<pid>/fd在這種情況下）

來源

2012-03-21 06:18:07 Hurkyl

，Hurkyl。是的，我終於找到了根本原因。我的應用程序在退出時並未終止所有被調用的遠程進程。 – user462872 2012-03-27 13:24:20

tail是查看文件結尾的命令，-f實時執行該操作，每當文件本身被修改時更新顯示。它允許實時查看日誌文件。

tail可能會導致問題在兩個方面：

如果tail -f一種是被不法寫入文件，而不是一個交互式控制檯，它是複製文件的效率低下的手段，它的創建重複的日誌。
tail -f使日誌文件保持活動狀態，因此嘗試自動刪除日誌文件的維護任務失敗。這會導致日誌文件的旋轉不允許舊的文件變老。

如果你的基礎架構團隊抱怨對文件的訪問比周齡少，你真的需要更多的驅動器空間和/或-詳細記錄少的策略，因爲它們不能保持足夠的日誌活着遇到問題並需要跟蹤。如果日誌比這個更早，它們可能有一個好的觀點，並且過多的使用tail - 就像保持文件打開的其他任何東西 - 可能會阻止它被及時刪除。

該命令本身不太可能會填滿磁盤，但可能會阻止磁盤衛生操作。

來源

2012-03-21 06:17:42

Adam，當我輸入命令「df -h」，並獲得低於 /dev/md/dsk/d1 59G 56G 2.5G 96％/ log 但是，如果我轉到日誌目錄，鍵入「 du -sh「，看起來這個foler的大小並不像上面顯示的那麼大：/ log> du -sh 10G。我們發現有很多「tail -f」進程，可能已經死了，讀取該文件夾中的日誌文件。因此我們懷疑那些尾部進程非常感謝空間 – user462872 2012-03-21 09:15:32

「tail -f」會使磁盤滿？

回答

相關問題