尋找原因

從字面上理解，這個問題是說磁碟上沒有多餘的空間。

那麼到底是什麼地方將空間？

1. 先用df命令檢視當前計算器磁碟空閒情況

df -a

我這邊執行完後可以看到/dev/vda1被完全佔用(找到對應的掛載點)

1. 從掛載點目錄下開始使用du命令查找出空間佔用最大的檔案

#檢視當前目錄下每個資料夾所佔用的空間
du -sh *

通過一層一層的比較檔案所佔用空間，發現是jenkins的執行日誌檔案佔用最大，本來我這邊的的伺服器磁碟僅100G，結果這個日誌檔案就有86G，我明白就是這個檔案將磁碟佔滿了

解決方案

我首先想到的是直接刪除該檔案，於是我進入到jenkins的目錄下，直接刪除了所有日誌。

rm -rf *.log

命令執行後，伺服器的其他程式臨時可以正常使用了。但是我執行df命令時發現/dev/vda1還是被完全佔用，但是我想應用都正常在運行了，那也許是系統需要重啟或過一段時間才能更新該狀態，我也就沒有再理會這個問題。

然而，這個問題並沒有就此結束。第二天同事發現應用又不能訪問了，我意識到昨天的那個問題還沒有結束。我再次執行了df和du命令，發現df的結果中表明/dev/vda1依然被全部佔用，而du的結果中卻沒有再發現大檔案了。我嘗試著將解決這兩種結果不一致的問題，興許解決後就能解決”No space left o device”的問題了。

根據兩個命令結果，我猜測應該是昨天直接通過rm

lsof | grep "jenkins.log"

列表中有很多程序都在開啟該檔案，雖然檔案刪除了，但是開啟該檔案的程序沒有關閉，也就是說檔案實際上還是存在，rm僅僅是刪除了該檔案的標記。

於是乎我果斷的終止了開啟該檔案的程序。

kill -9 22731

執行完畢後，再次執行df和du，發現結果相差不大了。到此係統又可以正常運行了。

雖然這個問題算是臨時解決了，但是jenkins的日誌為什麼可以達到86G？這個問題還沒有得到解決，由於這一次刪除的的充滿，沒有仔細看看日誌的內容，導致該問題的原因不太能夠查出。但是這個問題的根源肯定是沒有被解決的，只能等到下一次該問題出現後，好好研究一下該日誌，從根本上解決這個問題。

相關資料

另參考:

linux已刪除佔用空間的檔案了，為什麼磁碟還是顯示used 100%