近日我所維護的一臺伺服器執行出現了異常，翻開程式執行日誌，初步發現問題是某個過程無法建立新臨時檔案。 再仔細閱讀日誌，看到了Java報出的Java.io.IOException; there is not enough space on the disk。

那麼問題就很明顯了，磁碟佔滿了。但是這事本身就讓我很費解，因為這個伺服器上所跑的程式不會長期儲存檔案， 只是一個數據加工伺服器，把傳入的檔案進行一定的處理然後再回傳，期間會產生一些臨時檔案，但都會在處理 過程結束後自動刪除掉。我第一想到的就是，會不會是這個自動刪除的功能沒做好，導致臨時檔案堆積如山， 但是經過檢查，包括系統其他程式在內所產生的臨時檔案不到1G，根本不足以佔滿系統。

我執行df命令檢視磁碟的佔用情況，看到了4個磁碟掛載點，發現是掛載在/上的磁碟總共50GB被佔滿了。 於是我在根目錄執行du -h -x --max-depth=1想看看是哪個目錄佔用的這麼多空間，我好判斷到底出什麼問題了， 這個命令中的-x引數會讓du命令不統計不在同一個磁碟分割槽上目錄，或換句話說，忽略其他的磁碟掛載點。 結果令人崩潰，根本不用看哪個目錄有問題，整個根目錄總共統計，磁碟只佔用了5.5GB。 那麼50GB的磁碟被佔滿了，但是實際統計磁碟上的檔案，總共卻只有5.5GB大小，那麼剩餘的44.5GB被什麼鬼用掉了？

我只好進行我的Google功課，然後認識到了幾點非常重要的Linux特性。這個特性我以前也知道，卻沒有重視。 就是在Linux的檔案系統中刪除一個檔案，系統並不會真的立刻把這個檔案丟棄掉，而只是把它從檔案的目錄系統中移除， 只有確保所有使用這個檔案的程式全部都退出後，才會真的把檔案徹底刪除掉。所以這些幽靈檔案還會佔用磁碟空間， 不過這些幽靈檔案並不會出現在df

檔案系統作為Linux最核心的部件，工具也是最齊全的。lsof此時就可以針對此問題進行檢查了，這個命令是用來 列出整個系統中所有被開啟的檔案（順便還可以檢視所有已經啟動的硬體裝置以及開啟的網路連線等）。 已經從目錄系統中移除，但任然被程式佔用的的檔案可以用lsof | grep '(deleted)'來檢視。 經此我立刻就發現了我的問題在哪裡了：有一個已經被“刪除”掉的日誌檔案，因為並沒有關閉或重啟程式， 該檔案還在一直被使用著，還在忠實地記錄著程式的執行狀態。該程式已經持續執行半年了，而且日誌檔案一直都是 以同一個檔案開啟描述進行操作（日誌檔案只在程式開始時開啟過一次，後面一直用這個開啟的檔案）， 這個日誌檔案已經漲到40多GB了。

找到問題後，解決就簡單了，我重啟了那個程式，立刻40多G的佔用空間就歸還給了系統，所有程式都執行正常了。 當然這只是權宜之計，解決眼前問題採取的快速措施。要根除此問題就要用更科學的方式記錄日誌，使用已經成熟的 日誌系統是個比較正確的選擇