排除UC伺服器中的殭屍/已停用的進程故障
簡介
本文檔介紹如何使用Admin CLI登入時在CUCM、IMnP和其他思科UC產品上看到的殭屍進程。
必要條件
需求
思科建議您瞭解使用UC伺服器的管理CLI:
- 思科整合通訊管理員(CUCM)
- Cisco Unified Instant Messaging and Presence Server(IMnP)
- Cisco Unity連線伺服器(CUC)
採用元件
本文件所述內容不限於特定軟體和硬體版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。
背景資訊
統一通訊伺服器基本上是基於Linux作業系統的應用程式。當一個進程死於Linux時，並不是所有進程都立即從記憶體中移除，它的進程描述符(PID)停留在記憶體中，只佔用很少的記憶體量。此進程將變為已失效進程，並且該進程的父進程將收到其子進程已死亡的通知。然後，父進程應讀取失效進程的退出狀態，並將其從記憶體中完全刪除。使用wait()系統呼叫完成此操作後，將從進程表中刪除殭屍進程。這被稱為獲取殭屍進程。這通常發生得很快，因此您不會看到殭屍進程累積在系統中。
但是，有時父進程不執行wait()訊號呼叫，並且子進程將保留在記憶體中直到被清除。換句話說，殭屍進程是一個其執行已完成的進程，但它仍然具有進程表中的條目，因為父進程仍需要讀取其子進程的退出狀態。
使用UCOS管理CLI檢查殭屍
在CLI中，可以使用show process load 指令檢查殭屍是否存在。
手動排除/清除殭屍故障
除了前面提到的用於儲存PID的微記憶體之外，殭屍進程不使用任何系統資源，但會保留其進程ID。在UC伺服器中，提供給系統的記憶體大，因此系統由於存在殭屍而耗盡其他進程的PID的可能性很小。
因此，殭屍可以留在系統上，在下次系統重新啟動時，這些殭屍會自動被清除。
但是，如果要求清除系統中的殭屍程式，您可以遵循特定的操作線
重新啟動相應的服務
需要找出相關的流程，從而找出洩露子流程的服務。
- 在CLI輸出中，執行show process list和show process list detail的輸出。
- 在文本編輯器中複製輸出，並在檔案中搜尋文本「已失效」。
- 記下那些已失效進程的進程ID(pid)和父進程ID(ppid)。
- 在文檔中跟蹤PPID以查詢關聯的進程。
範例 1
CUCM:在檔案中搜尋「已停用」文本時，我發現存在一個22908已停用的PID。
該PID的PPID無效29815在文檔中跟蹤29815時，我認為該進程與AMC服務相關。
解決方案 — 重新啟動此節點上的AMC(警報管理器和收集器服務)清除殭屍。
範例 2
CUCM:搜尋已停用的文字的檔案時，可以看到存在已停10025的PID引數。
該PID的PPID無效。26732文檔中的跟蹤服務26732，您會看到該進程與跟蹤收集服務相關。
解決方案 — 重新啟動此節點上的跟蹤收集服務將清除殭屍。
範例 3
CUCM：在搜尋已失效文本的檔案時，您會看到有一個已失效23959PID引數。
該PID的PPID為26764。在文檔中的跟蹤26764，我看到該進程與CDR儲存庫服務(cdrrep)相關
解決方案 — 重新啟動CDR儲存庫服務清除此殭屍程式。
範例 4
CUC：在搜尋已停用的文本的檔案時，您會看到有三個PID 325、370和387已停用。
所有這些PID的PPID是7827。在文檔中跟蹤7827時，可以看到該進程與連線檔案同步器服務相關。
解決方案 — 重新啟動連線檔案Syncer服務會清除殭屍程式。
範例 5
IMnP：搜尋已失效文本的檔案時，您會看到有一個PID 1806已失效。
該PID的PPID是1775。在文檔中跟蹤1775時，您會看到該進程是到同一集群中另一個IMnP節點的SFTP連線。
解決方案 — 在IMnP中，可能會看到SFTP擁有的已停用的SSH進程。它們被發現是無關緊要的，可以通過重新啟動服務器將其刪除。
重新啟動伺服器
重新啟動相關伺服器會清除進程表中的所有過時條目，從而清除系統中的殭屍。
終止父進程
在Linux中，無法像使用SIGKILL訊號終止正常進程的方式終止殭屍進程 — 殭屍進程已死。但是，您可以終止父進程。該場景中使用的命令為：
kill -9 <ppid>
聯絡TAC以執行此解決方法。在終止父進程時確保小心，以確保不會突然中斷任何關鍵服務。
驗證
清除殭屍程式後，使用同一命令show process load檢查殭屍程式計數。
意見