OSSCE指令碼引發的重大問題，記在這裡以示警戒

今天發生的一件大事，早上9點多，線上服務的機器有一半不能訪問了。結果查看大多數的java進程被殺死，jboss伺服器停掉。也有的機器其它服務被停止。

 

最初懷疑是被入侵了。因為同時發生狀態一致的宕機，除非是時間BUG，否則如何那麼多機器都同時停止(已經排除人為操作原因)。

 

最後和安全部門聯絡，是否有統一的操作，結果他們反映地那個時間段統一停止了安全模組OSSCE，但它為什麼會導致JAVA應用和其它服務停止呢？

 

最後分析OSSCE的啟動指令碼，才發現問題的所在：

 

這個很爛的指令碼在啟動時開了一個lock，它不象其它軟體都是以進程或模組名為檔案名稱的，比如mysql.lock.這個爛人寫的指令碼是以OSSCE當前進程的進程ID為檔案名稱,比如當前進程ID為3333,則產生3333.pid,裡面的內容就是進程ID。

TMD的，如果你非要以進程號作為檔案名稱你直接touch一個0位元組的檔案從檔案名稱就可以擷取這個檔案表示的進程ID了。還多此一舉再往檔案中寫進程號。

 

關鍵是這個爛程式經常會自動crash.所以沒有調用stop,也就沒有調用清除檔案的命令。經過多次自動crash，多次手工重啟後，在一個目錄下留下大量的以進程號為檔案名稱的檔案。原來的進程號如果積累多了就和當前系統中很多進程的進程號相同。因為之前都是自動crash然後被重啟的，所以沒有手工調用stop，這次手動調用stop時，一次性清楚目錄中留下來的大量的以前的$PID.pid的檔案同時根據檔案中的pid(其實就是和檔案名稱中的$PID一致)一個個去kill,結果把當前進程中的很多進程給殺死了。

 

找到問題，但後續工作很麻煩，那麼多的機器，到底哪台機器的哪個進程被殺掉，無法統計。只能一一重啟。

這個爛人，你就不會以一個固定檔案名稱為lock,然後每次向其中寫入當前pid嗎？真是腦殘啊。還特別在stop時寫個指令碼列舉目錄下的所有檔案，要是用一個固定檔案名稱用得著列舉所有檔案嗎？