Jenkins假死问题记录

Jenkins假死问题记录

问题描述

昨天遇到一个问题,服务器掉电重启后,通过开机自启动脚本:
cd $JENKINS_HOME; nohup java -jar /usr/lib/jenkins/jenkins.war &
来启动。

启动后,登陆系统执行一个maven项目的编译job,此时其他人也进入系统执行自己的编译job,不到10分钟,发现编译脚本一直在转,但是控制台就是没有新的日志,同时其他同时反馈,系统没有反应。

问题定位

看到问题后,第一时间考虑的是通过杀掉jenkins进程,重新使用命令来重启jenkins服务。 结果实施后,发现问题还是跟原来一样,第一次进入系统正常,过一会jenkins又假死了。进程还在,但是就是不干活,无法退出,无法切换视图,执行的脚本就在一个进度上不停的旋转。

这时候考虑怀疑因为停电,导致jenkins的文件损坏 ,于是使用停电前的备份文件,进行恢复操作。然后再重启,然后发现问题还是一样。

又尝试了其他2次备份,结果也都如此。

这时候开始考虑是不是资源问题。使用top,vmstat发现,CPU,内存等资源都非常低,不是CPU,内存问题。

再使用netstat -nap | grep 8080, 发现jenkins有许多客户端连接状态为CLOSE_WAIT;
通过ps -ef|grep jenkins发现除了jenkins程序以外,还有 /tmp/XXX.sh脚本在运行。

于是打开/tmp/xxx.sh脚本,发现正是job执行的shell程序,然后进入到/tmp目录下,发现还有很多这样的脚本。

于是猜测,会不会跟这些脚本,在jenkins重启时被调用了导致。于是删除/tmp目录下所有的脚本还有一些不知道的其他临时文件,只保留了mysql.sock和mysql.sock.lock.

然后重启jenkins服务,再进入系统发现,一切问题都没了,jenkins又能正常工作了。

这里原因还是没搞明白,只能先记录下来经过和结果。后续遇到问题再慢慢研究。 因为这个问题从定位到解决花费了近5个小时,各种尝试,各种研究,甚至还影响了开发人员对于jenkins平台稳定的不信任。

问题总结

分析原因,可能是掉电时,程序正在执行任务,没有完成便被终止,临时脚本保留在了/tmp目录,因为正常情况下,jenkins在执行完shell后,都会从tmp中删除执行的脚本。 在jenkins重启时,这些临时脚本被默认调用或者加载到jenkins中,再次在jenkins中重新执行job的时候产生了锁,导致端口CLOSE_WAIT,系统处于假死状态。

你可能感兴趣的:(持续集成)