jenkins構建實例時出現「No space left on device」問題

問題以下：

背景：

出現這個問題，其實也有好一陣子了，查了硬盤空間以後發佈是由於jenkins 當時在部署時，放在了/dev/mapper/centos-root盤，這個盤只有40G，後來項目愈來愈多，加上構建數太大，以前是保留最近7次構建數，這裏提醒你們，jenkins 有提供了回滾功能，因此每一個構建記錄，其實裏面都有保留了你的war包。

解決辦法：

1. 使用命令：df -lk

使用命令：df -lk

發現果真有個磁盤已滿

二、使用命令：du --max-depth=1 -h 

查找大文件，發現/home文件夾下有17G的東西，由於個人apache是裝在/home下的，確定是網站運行的日誌文件佔用的空間

三、進入apache下的logs目錄

使用命令：ls -lht

查看文件的大小，果真有個8.6G文件，刪除便可。

四、再使用命令：df -lk

而後啓動apache和nginx沒有問題，解決。

五、出現這個錯誤第一反應是空間滿了。

df -h 一看卻發現還有挺多沒有用
df -i 一看發現是inodes空間滿了

####1.刪除掉沒用的臨時文件，釋放inodes

能夠到/tep目錄下看看有沒有不少sess_xxxx的session臨時文件

[root@test lib]#  ls -lt /tmp | wc -l
若是發現文件特別多，則：

[root@test lib]# find /tmp -type f -exec rm {} \;

####2.0字節的文件也會佔用一個inode，也必須刪除掉

遍歷查找並刪除

[root@test lib]# find /home -type f -size 0 -exec rm {} \;
####3.遍歷全部文件目錄找出佔空間大的文件，進行適當刪除

先遍歷出來佔的空間大的目錄

[root@test lib]# for i in /*; do echo $i; find $i | wc -l; done

（若是肯定是某個目錄下面，則/轉換爲該目錄絕對路徑，如/var/spool，則使用for i in /var/spool/*; do echo $i; find $i | wc -l; done）

通常來看是/var/spool底下的郵件相關的特別大。

[root@test lib]# find /var/spool/exim/msglog/ -type f -name ‘*’ -print0 | xargs -0 rm -rf

[root@test lib]# find /var/spool/exim/input/ -type f -name ‘*’ -print0 | xargs -0 rm -rf

六、先用df命令查看當前計算器磁盤空閒狀況
[root@test lib]#  df -a
我這邊執行完後能夠看到/dev/vda1被徹底佔用

從根目錄下開始使用du命令查找出空間佔用最大的文件
#查看當前目錄下每一個文件夾所佔用的空間
[root@test lib]#  du -sh *

經過一層一層的比較文件所佔用空間，發現是jenkins的運行日誌文件佔用最大，原本我這邊的的服務器磁盤僅100G，結果這個日誌文件就有86G，我明白就是這個文件將磁盤佔滿了

解決方案
我首先想到的是直接刪除該文件，因而我進入到jenkins的目錄下，直接刪除了全部日誌。

[root@test lib]#  rm -rf *.log
命令執行後，服務器的其餘程序臨時能夠正常使用了。可是我運行df命令時發現/dev/vda1仍是被徹底佔用，可是我想應用都正常在運行了，那也許是系統須要重啓或過一段時間才能更新該狀態，我也就沒有再理會這個問題。

然而，這個問題並無就此結束。次日同事發現應用又不能訪問了，我意識到昨天的那個問題尚未結束。我再次執行了df和du命令，發現df的結果中代表/dev/vda1依然被所有佔用，而du的結果中卻沒有再發現大文件了。我嘗試着將解決這兩種結果不一致的問題，興許解決後就能解決」No space left o device」的問題了。

根據兩個命令結果，我猜想應該是昨天直接經過rm命令刪除的文件空間沒有被釋放，因此我查看了系統中全部被打開的文件，在其中尋找到了那個日誌文件」jenkins.log」。

[root@test lib]#  lsof | grep "jenkins.log"

列表中有不少進程都在打開該文件，雖然文件刪除了，可是打開該文件的進程沒有關閉，也就是說文件實際上仍是存在，rm僅僅是刪除了該文件的標記。

因而乎我果斷的終止了打開該文件的進程。

[root@test lib]#  kill -9 22731

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

雖然這個問題算是臨時解決了，可是jenkins的日誌爲何能夠達到86G？這個問題尚未獲得解決，因爲這一次刪除的的充滿，沒有仔細看看日誌的內容，致使該問題的緣由不太可以查出。可是這個問題的根源確定是沒有被解決的，只能等到下一次該問題出現後，好好研究一下該日誌，從根本上解決這個問題。

7、重啓jenkins（把空間清理完畢後再操做）:   service jenkins restart

八、以上方法都嘗試過之後若是仍是不行，有可能鏡像構建和自啓動時間衝突致使！

根據鏡像名稱查詢容器ID並刪除

先 [root@test /]# docker ps -a    查看，若是有相應鏡像在運行，使用如下兩個命令移除

docker stop `docker ps -a | grep boss-report-provider | awk '{print $1}' `
docker rm   `docker ps -a | grep boss-report-provider | awk '{print $1}' `

直接使用docker stop images_name  和 docker rm  images_name 去操做正在運行的鏡像  若刪除不了使用強制刪除：docker rm -f images_name

若使用docker images 查看還有 刪除本地鏡像。
用docker rmi images_ID 移除

刪除全部是none的容器 docker rmi `docker images | grep  "<none>" | awk '{print $3}'`