关于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】