jenkins使用一段時間後，會致使出現比較大的日誌問題，常常佔滿硬盤空間（由於咱們使用的硬盤大小20G，無額外存儲要求）。在硬盤空間佔滿以後，會致使一些基本的命令都沒法使用，譬如tab都不能出結果。
其中顯示的日誌，就例以下面的樣例：
question: [DNSQuestion@1138295053 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
question: [DNSQuestion@815573059 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
question: [DNSQuestion@41696207 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
question: [DNSQuestion@2028905592 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
question: [DNSQuestion@1941181185 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
question: [DNSQuestion@641688452 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
question: [DNSQuestion@1165924047 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
question: [DNSQuestion@1220425596 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
question: [DNSQuestion@465635697 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
question: [DNSQuestion@1186949838 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
question: [DNSQuestion@2009482296 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
question: [DNSQuestion@1316653163 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
question: [DNSQuestion@1575193172 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
question: [DNSQuestion@1622635068 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
question: [DNSQuestion@630525334 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
並且咱們將已經定位到的文件刪除掉，仍然不能釋放空間，通過查看能夠深層次發現其中的問題。
未釋放磁盤空間緣由
在Linux或者Unix系統中，經過rm或者文件管理器刪除文件將會從文件系統的文件夾結構上解除連接(unlink).然而假設文件是被打開的（有一個進程正在使用），那麼進程將仍然可以讀取該文件，磁盤空間也一直被佔用。而我刪除的是jenkins的日誌文件，若是jenkins服務沒有中止，此時刪除該文件並不會起到什麼做用。
刪除的時候文件應該正在被使用
當linux打開一個文件的時候,Linux內核會爲每一個進程在/proc/ 『/proc/nnnn/fd/文件夾（nnnn爲pid）』創建一個以其pid爲名的文件夾用來保存進程的相關信息，而其子文件夾fd保存的是該進程打開的所有文件的fd（fd：file descriptor）。
kill進程是經過截斷proc文件系統中的文件可以強制要求系統回收分配給正在使用的的文件，這是一項高級技術，僅到管理員肯定不會對執行中的進程形成影響時使用。應用程序對這樣的方式支持的並很差，當一個正在使用的文件被截斷可能會引起不可預知的問題，因此最終仍是採用中止jenkins應用來解決該問題。
當一個文件正在被一個進程使用時，用戶刪除此文件，文件只會從目錄結構中刪除，但並無從磁盤刪除。當使用這個文件的進程結束後，文件纔會真正的從磁盤刪除，釋放佔有的空間。java
咱們發現剩餘磁盤空間比較少時，回去刪除一些大的臨時文件或者log文件，若是刪除以後會發現磁盤空間並未減小，那麼能夠經過「
lsof」命令去查看正在使用該文件的進程，而後再重啓該進程或者服務。
通常狀況下，jenkins的部署經常使用幾種方式：
- 經過系統服務安裝並啓動：service jenkins start/stop/restart，此時就能夠經過命令來中止；
- 將war包部署至tomcat中，此時stop tomcat服務器就能夠了。
而jenkins的日誌問題通過google一番，找出相應的幾個解決方法：
先考慮在jenkins上安裝兩個插件：
|
|
You can use the Logfilesizechecker Plugin:linux
Or, if this has also an impact on the runtime, the Build-timeout Plugin:服務器
|
在jenkins中也已經意識到了該問題，並有了初步的解決方案：
根據朱迪的調研，考試使用下面的方式來解決此問題：
This seems to be due to DNS multicast as explained here: https://issues.jenkins-ci.org/browse/JENKINS-25369 Workaround: add -Dhudson.DNSMultiCast.disabled=true to JAVA_ARGS. PS: I'm answering my own question here on Stack Overflow because I couldn't find the answer on Google easily, and it will be useful to other people running Jenkins.
日誌中出現過多的DNS相關錯誤。
此外，還有一些其餘須要值得注意的點，例如在腳本中若是涉及到啓動進程的話，須要加入BUILD_ID，不然該進行啓動後就會被kill掉。
若是不設置BUILD_ID，則jenkins在結束本身的腳本執行時會將建立的全部subprocess kill掉，BUILD_ID是Jenkins的一個環境變量，若是不隨便改爲一個值，那麼因爲startup.sh是fork一個進程執行的，Jenkins執行完全部腳本就會退出，帶着subprocess一塊兒死掉，具體的解釋緣由詳見：