關於Jenkins日誌爆滿的解決方法

最近發現公司的jenkins由於日誌量太大把磁盤佔滿，查看日誌文件「/var/log/jenkins/jenkins.log」幾分鐘產生了幾十G的日誌

並且日誌還在一直增加，內容以下

 120: 31303040312e312e 312e313e0d0a436f 6e746163743a2073 69703a3130304031     100@1.1. 1.1>..Co ntact:.s ip:100@1
 140: 32372e302e312e31 3a353236370d0a43 5365713a2031204f 5054494f4e530d0a     27.0.1.1 :5267..C Seq:.1.O PTIONS..
 160: 43616c6c2d49443a 2032333736353733 3036343830373737 3236373837343730     Call-ID: .2376573 06480777 26787470
 180: 300d0a4d61782d46 6f7277617264733a 2037300d0a0d0a                        0..Max-F orwards: .70....

Nov 26, 2018 1:09:31 PM javax.jmdns.impl.DNSIncoming$MessageInputStream readName
SEVERE: bad domain name: possible circular name detected. Bad offset: 0xffffffff at 0x195
Nov 26, 2018 1:09:31 PM javax.jmdns.impl.constants.DNSRecordType typeForIndex
SEVERE: Could not find record type for index: -1
Nov 26, 2018 1:09:31 PM javax.jmdns.impl.DNSIncoming readAnswer
SEVERE: Could not find record type. domain: 
dns[query,62.210.116.113:5267, length=407, id=0x4f50, flags=0x5449:aa, questions=20302
questions:
        [DNSQuestion@1698506285 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: 00@101.200.87.125 SIP/2.0
Via: SIP/2.0/UDP 127.0.1.1:5267;branch=z9hG4bK-1805463161;rport
Cont.Length: 0
From: "sipvicious"<sip:100@1.1.1.1.;tag=3635633835373764313465390132303839373931373930
Accept: a.sdp
User-Agent: friendly-scanner
To: "sipvici.<sip:100@1.1.1.1>
Contact: sip:10.@127.0.1.1:5267
CSeq: 1 OPTIONS
Call-ID: 23765.306480777267874700
Max-Forwards: 70

ϿϿϿϿϿϿϿϿ.]
        [DNSQuestion@690369214 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@1821236921 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@1695940198 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@1763025063 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@1908329721 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@1933884513 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@971545249 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@2109478307 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@2053294057 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@747887472 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@1372811729 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@1281320773 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@544124072 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@311733134 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@1476595188 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@1867595006 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@982500944 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@233886292 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@1297875635 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]
        [DNSQuestion@730624298 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應用來解決該問題。

 

當一個文件正在被一個進程使用時，用戶刪除此文件，文件只會從目錄結構中刪除，但並無從磁盤刪除。當使用這個文件的進程結束後，文件纔會真正的從磁盤刪除，釋放佔有的空間。

 

 

此外，還有一些其餘須要值得注意的點，例如在腳本中若是涉及到啓動進程的話，須要加入BUILD_ID，不然該進行啓動後就會被kill掉。

 

若是不設置BUILD_ID，則jenkins在結束本身的腳本執行時會將建立的全部subprocess kill掉，BUILD_ID是Jenkins的一個環境變量，若是不隨便改爲一個值，那麼因爲startup.sh是fork一個進程執行的，Jenkins執行完全部腳本就會退出，帶着subprocess一塊兒死掉，具體的解釋緣由詳見：

 

https://wiki.jenkins-ci.org/display/JENKINS/ProcessTreeKiller

 

上面內容主要是由於DNS查詢錯誤，返回了全部的日誌數據，解決方法：

系統管理】=》【system log】=>【日誌級別】=》【Name: javax.jmdns,Level: off】