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,系统处于假死状态。