简介
本文档介绍如何查找并排除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.硬件故障
崩溃背后的原因
在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：请注意，核心文件与发生崩溃的PID相对应。核心文件以“crash-<card no>-<cpu>-<pid>-<unixtime>-core”格式命名。您可以在“show crash list”命令输出中找到此信息。
Minicore文件：此文件包含有关失败任务的信息，包括当前堆栈跟踪、过去的分析器示例、过去内存活动示例以及其他专有文件格式的捆绑数据。
Core Dump（或Full Core）：核心转储在崩溃发生后立即提供进程的完整内存转储。此内存转储通常对于确定软件崩溃的根本原因至关重要。
崩溃签名：可以从共享的显示支持详细信息(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
现在，如果您想了解崩溃1的签名，请在SSD中搜索崩溃#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.需要解析核心文件/微核心，以分析回溯并获取设备崩溃功能的线索。
3.完成核心文件调试后，您需要用软件缺陷验证症状，以及是否存在任何现有的软件缺陷，用于类似的故障签名和回溯。
会话恢复
StarOs软件旨在处理可预见的条件/事件和不可预见的条件/事件。尽管思科努力开发完美的软件，但不可避免地存在错误，并且可能会发生故障。这正是会话恢复功能如此重要的原因。
当系统内的硬件或软件发生故障时，会话恢复功能提供无缝故障切换和用户会话信息的重建，以防止完全连接的用户会话被断开。通过在系统中镜像关键软件进程（例如，会话管理器和AAA管理器）执行会话恢复。这些镜像进程保持空闲状态（备用模式），在此状态中它们不执行任何处理，直到在软件发生故障（例如，会话管理器任务中止）时可能需要它们为止。
解复用器任务、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
反馈