目錄

簡介

概觀

崩潰案例

Crash背後的原因

不同型別的崩潰

初始日誌要求

分析步驟

會話恢復

簡介

本文檔介紹如何查詢並排除StarOs設施崩潰故障。

概觀

有時，系統邏輯可能失敗，從而導致軟體任務重新啟動以恢復正常功能。這可能導致進程崩潰。StarOS中經常報告任務設施崩潰，並且可以根據崩潰的根本原因採取必要的操作。要識別節點上的崩潰，您可以使用以下CLI命令：

******** show crash list *******

Saturday April 15 05:05:56 SAST 2023

=== ==================== ======== ========== =============== =======================

#           Time         Process  Card/CPU/        SW          HW_SER_NUM

PID         VERSION       CF / Crash Card

=== ==================== ======== ========== =============== =======================

1   2022-Dec-02+14:08:46 confdmgr 02/0/19342 21.26.13        NA

2   2022-Dec-02+14:48:08 confdmgr 02/0/31546 21.26.13        NA

3   2022-Dec-04+19:10:50 sessmgr  03/0/12321 21.26.13        NA

4   2022-Dec-21+03:34:13 sessmgr  04/0/12586 21.26.13        NA

類似的崩潰被合併到一個記錄中。記錄會顯示此崩潰型別的發生次數。

********************* CRASH #02 ***********************

SW Version          : 21.26.13

Similar Crash Count : 33 >>>>

Time of First Crash : 2022-Dec-02+14:10:05

Assertion failure at confdmgr/src/confdmgr_fsm.c:870

Note: State machine failure, state = 3

Function: confdmgr_fsm_state_wait_p0_handler()

Expression: 0

Code: CRASH

Proclet: confdmgr (f=1900,i=0)

Process: card=2 cpu=0 arch=X pid=31546 argv0=confdmgr

在  show snmp trap history verbose輸出顯示某個進程已崩潰：

Fri Dec 26 08:32:20 2014 Internal trap notification 73 (ManagerFailure) facility sessmgr

instance 188 card 7 cpu 0

Fri Dec 26 08:32:20 2014 Internal trap notification 150 (TaskFailed) facility sessmgr instance

188 on card 7 cpu 0

Fri Dec 26 08:32:23 2014 Internal trap notification 1099 (ManagerRestart) facility sessmgr

instance 139 card 4 cpu 1

Fri Dec 26 08:32:23 2014 Internal trap notification 151 (TaskRestart) facility sessmgr

instance 139 on card 4 cpu 1

崩潰案例

崩潰的原因可能有多種：

1.不同的呼叫流程場景

2.記憶體問題

3.配置問題

4.硬體故障

Crash背後的原因

在StarOS中有多個任務工具，它們各自具有基於這些功能的功能，因此，每當工具遇到任何此類輸入，並且進入有問題的狀態，它會使工具崩潰以從該錯誤狀態中恢復。

不同型別的崩潰

1.斷言失敗：

********************* CRASH #22 ***********************

SW Version          : 21.26.13

Similar Crash Count : 33

Time of First Crash : 2023-Apr-12+22:40:01

Assertion failure at sess/smgr/sessmgr_snx.c:9568 >>>>

Function: sessmgr_snx_send_drop_call()

Expression: result == SN_STATUS_SUCCESS

Proclet: sessmgr (f=87000,i=261)

Process: card=5 cpu=0 arch=X pid=12724 cpu=~0% argv0=sessmgr

2.分段錯誤：

********************* CRASH #69 ***********************

SW Version : 21.13.3

Similar Crash Count : 2

Time of First Crash : 2019-Nov-25+07:53:54

Fatal Signal 11: Segmentation fault >>>>

Faulty address: 0x7ff6b4801036

Signal from: kernel

Signal detail: address not mapped to object

Process: card=8 cpu=1 arch=X pid=7316 argv0=vpp

Crash time: 2020-Feb-11+04:04:23 UTC

Build_number:

3.致命訊號：

********************* CRASH #01 ***********************

SW Version          : 21.23.12

Similar Crash Count : 2

Time of First Crash : 2023-Jan-27+05:22:46

Fatal Signal 11: 11  >>>>>

PC: [04be6859/X] sessmgr_pgw_create_bearers()

Faulty address: 0x297116e4

Signal from: kernel

Signal detail: address not mapped to object

Process: card=9 cpu=1 arch=X pid=10383 cpu=~8% argv0=sessmgr

初始日誌要求

崩潰日誌是崩潰事件資訊的寶貴來源。當軟體崩潰發生時，StarOS會捕獲並儲存相關資料，以幫助確定崩潰的原因。此資訊可以儲存在系統記憶體中，也可以傳輸並儲存在網路伺服器上。

Core File或Mini Core File：請注意，core檔案與發生崩潰的PID相對應。核心檔案的命名格式為「crash-<card no>-<cpu>-<pid>-<unixtime>-core」。您可以在「show crash list」命令輸出中找到此資訊。

Minicore檔案：此檔案包含有關失敗任務的資訊，包括當前堆疊跟蹤、過去的探查器示例、過去的記憶體活動示例以及其他專有檔案格式的捆綁資料。

Core Dump（或Full Core）：核心轉儲在崩潰發生後立即提供進程的完整記憶體轉儲。此記憶體轉儲通常對於確定軟體崩潰的根本原因至關重要。

崩潰簽名：可以從共用的Show Support Details(SSD)或其他相關來源檢視崩潰簽名。

******** show crash list *******

Saturday April 15 05:05:56 SAST 2023

=== ==================== ======== ========== =============== =======================

#           Time         Process  Card/CPU/        SW          HW_SER_NUM

PID         VERSION       CF / Crash Card

=== ==================== ======== ========== =============== =======================

1   2022-Dec-02+14:08:46 confdmgr 02/0/19342 21.26.13        NA

2   2022-Dec-02+14:48:08 confdmgr 02/0/31546 21.26.13        NA

3   2022-Dec-04+19:10:50 sessmgr  03/0/12321 21.26.13        NA

現在，如果您想瞭解crash 1的簽名，請在SSD中搜尋CRASH #01，或在CLI中使用show crash number 1。

From SSD

********************* CRASH #01 ***********************

SW Version          : 21.26.13

Similar Crash Count : 1

Time of First Crash : 2022-Dec-02+14:08:46

Assertion failure at confdmgr/src/confdmgr_fsm.c:758

Note: State machine failure, state = 5

Function: confdmgr_fsm_state_wait_p1_handler()

Expression: 0

Code: CRASH

Using CLI

[local]abc# show  crash number 1

Friday June 09 06:41:53 CDT 2023

********************* CRASH #01 ***********************

SW Version          : 21.12.20.77760

Similar Crash Count : 1

Time of First Crash : 2021-Mar-31+15:58:06

Fatal Signal 6: Aborted

PC: [ffffe430/X] __kernel_vsyscall()

Note: User-initiated state dump w/core.

Signal from: sitmain pid=6999 uid=0

Process: card=9 cpu=0 arch=X pid=9495 cpu=~0% ar

在出現問題的特定時間戳期間檢查顯示支援詳細資訊(SSD)和系統日誌。

分析步驟

1.需要檢查故障堆疊/簽名，並檢查該特定故障簽名是否有錯誤。

2.需要分析核心檔案/minicore以分析回溯並獲取有關設施崩潰的功能的線索。

3.核心檔案調試完成後，您需要驗證軟體缺陷的症狀，以及是否存在類似故障簽名和回溯的軟體缺陷。

會話恢復

StarOs軟體旨在處理可預見的條件/事件和不可預見的條件/事件。儘管思科努力擁有完美的軟體，但不可避免的錯誤確實存在，而且可能會發生故障。這就是會話恢復功能如此重要的原因。

當系統內的硬體或軟體故障防止完全連線的使用者會話斷開時，會話恢復功能提供無縫的使用者會話資訊的故障切換和重建。會話恢復是通過在系統中映象關鍵軟體進程（例如，會話管理器和AAA管理器）執行的。這些映象進程保持空閒狀態（備用模式），在此狀態下，它們不執行任何處理，直到在軟體發生故障（例如，會話管理器任務中止）時可能需要它們為止。

Demux任務、AAA管理器和VPN管理器等任務在我們的系統中具有內建自動恢復機制，專門用於處理使用者資訊。會話恢復主要指sessmgr任務出現故障或卡級故障，並且會話需要恢復而不丟失任何呼叫的情況。

- 在系統中，備用會話管理器在每個處理卡上處於活動狀態，在發生故障時可以快速接管主sessmgr。然後在處理卡上建立新的備用sessmgr。

- 當sessmgr進程意外失敗時，備用sessmgr從aamgr（AAA管理器）檢索備份資訊並重新建立其會話。

- 如果aaamgr失敗，備用aamgr將查詢sessmgr以同步相關的使用者資訊。

- 當demux-mgr發生故障時，它將查詢所有會話並重新構建其呼叫分佈資訊資料庫。

- 為了確保卡級冗餘，一個處理卡用作備用卡，隨時可在硬體或軟體出現故障時進行接管。然後，備用卡從運行在其他卡上的對等管理器恢復會話。

******** show session recovery status verbose *******

Saturday April 15 05:11:17 SAST 2023

Session Recovery Status:

Overall Status        : Ready For Recovery  >>>>

Last Status Update    : 5 seconds ago

----sessmgr---  ----aaamgr----  demux

cpu state    active standby  active standby  active  status

---- -------  ------ -------  ------ -------  ------  -------------------------

3/0 Active   40     1        40     1        0       Good

4/0 Active   40     1        40     1        0       Good

5/0 Active   40     1        40     1        0       Good

6/0 Active   40     1        40     1        0       Good

7/0 Active   0      0        0      0        10      Good (Demux)

8/0 Active   40     1        40     1        0       Good

9/0 Active   40     1        40     1        0       Good

10/0 Active   40     1        40     1        0       Good

11/0 Standby  0      40       0      40       0       Good