一次離奇的腳本失效原因查找過程

背景

最近公司爲了實現研發區域和測試區域的網機器網絡隔離.
將測試機器整天進行了遷移, 過程中需要關機和搬遷
以及更換網絡地址等步驟. 
前期爲了提高產品的日誌查看. 使用了NFS掛載的方式收集日誌. 
因爲NFS日誌服務器也進行了遷移, 所以導致了一系列的問題. 
這裏簡單總結一下.

問題現象

因爲規劃問題, 部分服務器沒有發生變化. 機器同時也是開着的.
然後發現部分機器之前正常運行了一年多的啓動腳本出現了異常.
會卡死然後無法正常啓動服務. 以及進行郵件發送等動作. 
非常奇怪. 

解決過程1

個人感覺調試腳本與調試程序方法和道理是一樣的. 
我根據輸出的日誌發現在某個腳本上卡死了
然後在腳本內部添加 echo 驗證執行到什麼命令式出現異常. 
類似於開發調試代碼時的斷點處理.

結果很明顯就發現到了 lsof -i:xxxx 獲取活動進程信息時 出現了異常卡死的現象.
根據此 需要進一步分析

解決過程2

使用 strace 根據 lsof 具體命令的調用棧
starce lsof -i:5200
然後會進行很長時間的 輸出
最後定位到一個具體的進行信息的文件內容 比如我這個的內容是 
/proc/20406/fd/4
這裏就很詭異了 然後程序卡住了
要分析下一具體因爲什麼卡住了.
ps -ef |grep 20406 發現是tee進程寫入 nfs 掛載點的問題
這樣就有眉目了 
kill -9 20406 
但是發現並沒有效果. 進程依舊堅挺
推測應該是tee 和 NFS在NFS失效時出現了內核bug 導致進程都無法kill
沒辦法只能採取重啓打法好.

解決過程3

重啓後, 發現沒有了 NFS掛載點
tee的進程也沒有了.
然後腳本就又可以正常使用了.
這個裏面充分說明 重啓服務器在很多情況下能夠解決問題
這次雖然水了篇文章, 但是也從原理上明白了爲何會這樣.

這裏在補充一點的是 NFS服務器宕機之後 很奇怪的是 
我使用 finalshell的方式都看不到文件和右側的路徑信息等.
今天在解決一個服務器xfs 文件損壞時 學到了一個 
umount -lf /NFS_PATH的命令 然後立馬就用了一下
發現就可以理解展開文件和取消掛載了. 
發現命令是無窮盡需要學習的. 知識點非常龐雜. 

總結

重啓大法好
多學一點沒壞處.
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章