无限挂掉的tomcat生产事故

故事背景

最近突然发现一个很奇葩的BUG，在同事的一次离线服务升级后，过了几小时，运营反映系统访问异常，我一看tomcat自动关闭了，当时我还没知道事情的严重性.....明天早上系统又又挂了，我们就开始问题的追踪。

问题分析

这一次升级在代码层面只是更新了某个字段的取值，然后同事在优化JVM参数里面优化了一些jvm日志参数

shell 复制代码

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/xxx/oom.hprof -XX:+PrintGCDetails -XX:+PrintGCDateStamps

同时打包模式也发生了改变，之前离职的同事是用eclipse打包，现在用的idea。

问题跟踪

首先服务挂掉时间是不定时的，有时候是上午有时候是下午，有时候是凌晨。他们写了一个shell脚本，再监控到服务关闭后自动重启，避免服务停掉影响用户使用。

shell 复制代码

#!/bin/bash


while true;
do
if [[ -z $(ps -ef|grep 'catalina.base=/home/xxx/tomcat'|grep -v grep| awk '{print $2}') ]]
then
  echo "`date` /home/xxx/tomcat is not running." >> /opt/ott/log/ottoffline_gc/monitoring.log
  sleep 10;
  cd /home/xxx/tomcat
  ./bin/startup.sh
  echo "`date` /home/xxx/tomcat Starting" >> /data/xxx/log/monitoring.log
else
  echo "`date` /home/xxx//tomcat is running." >> /data/xxx/log/monitoring.log
fi
sleep 5;
done

先是ps -ef|grep 查看服务是否存在，不存在则进入到tomcat目录启动tomcat。用nohup monitor.sh >/dev/null 2>&1 & 后台启动。 grep 'not running'可以看到服务挂掉的时间（有一些是手动关闭重启）

这个tomcat挂掉的原因分析有两个方向，要么是数据量太大内存溢出的OOM崩溃，就是JVM的保护机制。要么是linux检测到tomcat内存过大自动kill掉。从这两个方向我们分别查看对应的日志。

tomcat:catalina.out日志、localhost.xxx.log(not such method 等error错误日志)、log4j的error日志等。没发现异常。

linux: 一般来说系统日志会在/var/log/messages里面，如果是系统kill掉的进程会在这个日志，类似下图

但是看我们的服务器日志没有打印messages，grep 'kill' /var/log/* 也没看到日志。通过日志找到崩溃原因的线索断了..

又一个BUG

在top命令查看CPU和内存信息后，看到某一个grep CPU占用率100%.....某一个同事想找一个某个字符串在系统有没有用到 grep -rn 'xxx' /* 可能关闭控制台了导致后台一直在搜索。一个神奇的事情是，我用kill -9 pid kill不了该进程。求助gpt的kill -15、 sudo kill -9 、pkill等命令都删不了。 cat /proc/{pid}/status 查看线程状态和pid，状态是running，pid是本身，ppid是1。也不能把1干掉，貌似只能重启服务器了...（事实证明不要乱用 /*）

回滚配置

书接上回，查日志找不到关键信息后，只能通过控制变量法来处理了。用回旧的包还是会崩溃，说明不是代码问题，那就是jvm配置或者打包部署的时候有问题。在查看日志的时候发现系统启动的时候配置加载了两次，定时任务也执行了两次。

打开tomcat/webapps 发现有两个文件夹，一个是正式的，一个是备份的，tomcat把两个都加载了,难道就是因为这个问题导致的？当我信心满满把备份的移到其他地方再观察服务，发现还是会挂掉。

最后我使出最后的绝招，换了个tomcat版本，把jvm配置还原到以前的配置，重新打包上去，现在观察ing

最后发现把所有东西都还原了，系统就好了，估计是某个jvm配置导致tomcat挂掉- -