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