一次信號量引起的tomcat異常退出

 

近期在玩大數據。有個朋友找過來，說他線上的tomcat會莫名其妙的退出，表示很是苦惱，請我幫看看。每次他發現退出了，都經過騰訊雲的WEB控制檯登陸，啓動tomcat。

本着助人爲樂(shao kao hao chi)的精神，我連上去開始分析。首先確定是看tomcat的日誌，看看有沒有記錄到相關信息，是什麼途徑退出的。

從日誌上看，tomcat收到了退出請求，並按照要求關閉容器。那麼是否能夠認爲是有人執行了shutdown.sh呢？並不能。執行了shutdown腳本的關閉日誌是這樣的。

與其相關的tomcat源碼截圖以下。截圖左側有行號。

tomcat啓動時，設置await，等待關閉指令進入。org\apache\catalina\startup\Bootstrap.java 

catalinaDaemon的定義以下。

 org\apache\catalina\startup\Catalina.java

 

具體實例化時，會將接口Server的實例指向StandardServer。類路徑以下。

org\apache\catalina\Server.java

org\apache\catalina\core\StandardServer.java

而StandServer中的輸出相關日誌的源碼以下： 

 讀取的配置文件爲org\apache\catalina\core\LocalStrings.properties

當tomcat收到正經的關閉指令時，會輸出此日誌，說明是收到指令關閉容器。

 正經的指令關閉容器，相關代碼以下。

那麼，如今的證聽說明，這個tomcat不是經過SHUTDOWN報文關閉的。並且，從下圖來看，也頗能說明這個SHUTDOWN指令不是這麼容易發成功的。

那麼如今可能性最大的辦法就是經過KILL指令來操做。執行bash腳本須要登陸機器，那麼從wtmp、utmp查找一下這個時間點的登陸記錄呢？

下面是IPIP的結果。

 

 換言之，23日早上tomcat異常退出的時候，有一個來自騰訊雲的BGP機房的地址也巧合的斷開了會話。而我這個朋友的機器就放在騰訊雲。有點奇怪是嗎？

繼續追查，連續追溯幾天的tomcat日誌，比對utmp、wtmp結果，再比對IPIP結果，都是如此。來自騰訊雲BGP機房的會話斷開，tomcat同一時間點退出。精確到秒級。連續多天出現不少次，說明tomcat退出和WEB會話退出是具有因果關係的。

通過詢問，朋友確認他是習慣於使用WEB控制檯的方式登陸服務器，啓動了tomcat之後就丟在一邊，開始調試接口了。那麼有什麼可能會致使這樣的因果關係出現？這就要說到Linux系統的一個歷史悠久的進程間通訊的機制——信號量。

具體信號量是什麼，請自行查詢相關資料瞭解學習。針對本次問題，能夠簡單的理解爲進程間通信的一種機制。

進程A須要進程B作點事，而進程間的內存區域某種意義上說是互不可見的。這個時候就須要經過信號量來完成。進程A能夠按照預先定義的信號量規範向進程B發出信號量，當進程B收到後，根據具體信號量的值決定處理邏輯。具體信號量清單，能夠在命令行經過以下命令查詢。命令中均爲字母，沒有數字1。

這其中最多見的就是9，SIGKILL。當進程收到此信號量時，會被KILL掉。此信號量由操做系統處理，應用不能處理。在vista以前的windows系統中，是有辦法滲透到內核中的。此時能夠攔截相似WM_CLOSE之類的消息，讓某個程序沒法關閉。到了win七、win10時代，已經不能使用此類技巧了。

此外，咱們熟悉的CTRL + C操做，發出的是SIGINT。有些場景下，咱們須要通知程序優雅的退出，此時能夠發出SIGQUIT，也就是kill -3。

那麼WEB控制檯會話斷開，會發出什麼信號量呢？咱們來試試就知道了。Java雖說不能操做系統底層，可是sun.misc包有驚喜哦。代碼以下。

 

如圖所示，這段代碼會在收到信號量時輸出線程名稱，信號量名稱，並翻譯成具體的數字。隨後，在main函數中，我「註冊」了HUP、INT、ABRT、TERM四種信號量。註冊四種是由於不清楚具體會發什麼出來，索性有可能的都搞起來。

編譯，打包。此處有一個問題須要注意，因爲信號量屬於操做系統底層機制，每一個不一樣操做系統所支持的信號量是不一樣的，JVM中經過private static native int findSignal(String paramString)提供支持。native方法涉及具體VM實現，不貼代碼了。不過很容易想到的是，windows和linux固然不一樣。因此此處就要在上位機編寫，下位機調試了。windows底下運行報錯可不要慌張哦。

接下來的事情就簡單了。把程序上傳服務器，經過WEB控制檯登陸服務器，將執行結果重定向到文本文件中，而後靜待控制檯超時。結果以下。

結果不用再分析了，WEB控制檯會在退出時發出SIGHUP，至關於kill -1。而tomcat在收到SIGHUP會怎麼操做呢？小夥伴們能夠試試看kill -1 pid，再看看日誌，就明白了。

解決方案其實也簡單。SIGHUP是HANG UP的意思，能夠用nohup xx.sh &來完全屏蔽SIGHUP和SIGINT。另外，通過測試發現，經過單擊SecureCRT的tab頁右側的×也能夠觸發信號量，而直接logout或者點菜單上的紅叉則並不會觸發。

感興趣的小夥伴能夠把這個程序擴展一下，測測看。說不定你的異常退出問題也能迎刃而解呢。

此問題的解決離不開上海中通的劉建剛同窗，特此致謝。