Tomcat进程意外退出的问题分析

早上6点接到电话java服务器挂掉了，本能的立刻清醒起来查看服务器状态，发现tomcat确实停止运行了，立刻的重启了之后去找问题所在(ps：这个问题体现了集群负载均衡是多么重要，服务器几乎崩溃一晚上)

错误排查思路：首先想到的是服务器是否负载导致tomcat闪退（stackoverflow/outofmemoryerror），hs_err_pid.log文件未生成，表明jvm正常运行，然后去查看tomcat日志

此处显示tomcat停止于02:53:00，而且无任何错误，tomcat是正常关闭的！！！看清楚这是正常关闭的，根本不存在负载退出的情况

本能想到怕是要被黑客爆ju了，查看了tomcat最后的访问地址无异常

查看服务器负载情况（指系统，因为使用的是阿里云服务器，当然的有记录崩溃时服务器的运行状态）一切正常，无任何可疑地方，使用stat "命令地址" 查询系统命令是否有修改过

例如：

未发现异常，继续查询远程终端登录情况last 命令查询

登录终端也是正常，都是本人自己的ip，试想好不好被linux终止了tomcat进程于是去查询/var/log/message 日志信息

未发现异常，紧接着去查询/var/log/secure日志文件

这次发现了有趣的事情，sshd关闭了远程连接时间与tomcat进程终止时间完全吻合，定位了问题之后就方便多了，查询了一些资料之后重现了tomcat进程“闪退”，总的来说是因为发布版本完成之后未关闭shell脚本，脚本还在挂着tailf查看日志，电脑休眠之后sshd主动关闭了远程连接，java进程仍属于shell进程组里的成员，收到SIGHUP后退出，自己写了个简单的脚本重现了当时的情况。确定了问题就是这个原因。

如果我们在shell脚本里设置开启作业控制的话，就不会让tomcat进程退出了，总算是虚惊一场，是自己的原因导致tomcat进程结束，并不是黑客入侵~

总结：启动完成之后需要关闭退出脚本，就不会出现sshd关闭远程连接而使进程终止了，当然更好的办法是在脚本中加入设置开启作业控制(分开进程组)就不会出现这个问题啦~

每个人碰到的闪退问题可能不一致，但排查的思路还是值得学习的～

借鉴文章：http://ifeve.com/why-kill-2-cannot-stop-tomcat/

set -m