这篇文章主要介绍如何解决因信号量引发tomcat异常退出的问题,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!
近期在玩大数据。有个朋友找过来,说他线上的tomcat会莫名其妙的退出,表示非常苦恼,请我帮看看。每次他发现退出了,都通过腾讯云的网络控制台登录,启动tomcat。
本着助人为乐(邵拷郝chi)的精神,我连上去开始分析。首先肯定是看tomcat的日志,看看有没有记录到相关信息,是什么途径退出的。
从日志上看,tomcat收到了退出请求,并按照要求关闭容器。那么是否可以认为是有人执行了关闭。sh呢?并不能。执行了关闭脚本的关闭日志是这样的。
与其相关的tomcat源码截图如下。截图左侧有行号。
tomcat启动时,设置在等待,等待关闭指令进入启动.org \ apache \卡特琳娜\ \引导。java
catalinaDaemon的定义如下。
org \ apache \卡特琳娜\启动\卡特琳娜。java
具体实例化时,会将接口服务器的实例指向StandardServer。类路径如下。
org \ apache \卡特琳娜\ Server.java
org \ apache \卡特琳娜\ \ StandardServer核心。java
而StandServer中的输出相关日志的源码如下:
读取的配置文件为org \ apache \卡特琳娜\ \ LocalStrings核心。properties
当tomcat收到正经的关闭指令时，会输出此日志，说明是收到指令关闭容器。
正经的指令关闭容器，相关代码如下。
那么，现在的证据说明，这个tomcat不是通过SHUTDOWN报文关闭的。而且，从下图来看，也颇能说明这个SHUTDOWN指令不是这么容易发成功的。
那么现在可能性最大的办法就是通过KILL指令来操作。执行bash脚本需要登录机器，那么从wtmp、utmp查找一下这个时间点的登录记录呢？
下面是IPIP的结果。
换言之，23日早上tomcat异常退出的时候，有一个来自腾讯云的BGP机房的地址也巧合的断开了会话。而我这个朋友的机器就放在腾讯云。有点奇怪是吗？
