簡介
本文檔介紹如何查詢並排除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任務出現故障或卡級故障，並且會話需要恢復而不丟失任何呼叫的情況。
******** 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
意見