Introdução
Este documento descreve como localizar e solucionar problemas de travamentos de recursos do StarOs.
Overview
Às vezes, a lógica do sistema pode falhar, fazendo com que uma tarefa de software seja reiniciada para restaurar a funcionalidade apropriada. Isso pode levar a um travamento de processo. Travamentos de recurso de tarefa são frequentemente relatados no StarOS, e as ações necessárias podem ser tomadas com base na causa raiz do travamento. Para identificar travamentos no nó, você pode usar este comando 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
Travamentos semelhantes são consolidados em um registro. O registro não exibe o número de vezes que esse tipo de travamento ocorreu.
********************* 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
IN show snmp trap history verbosemostra que algum processo travou:
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
Cenário de travamentos
Pode haver vários motivos diferentes para travamentos:
1. Diferentes cenários de fluxo de chamadas
2. Problemas de memória
3. Problema de configuração
4. Falhas de hardware
Motivo por trás do travamento
Você tem vários recursos de tarefas no StarOS com suas funcionalidades individuais tão baseadas nas funções, sempre que o recurso encontra qualquer entrada onde está entrando em um estado problemático, ele trava o recurso para se recuperar desse estado de erro.
Tipos diferentes de travamento
1. Falha de declaração:
********************* 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. Falha de segmentação:
********************* 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. Sinal Fatal:
********************* 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
Requisito de registros iniciais
O registro de falhas serve como uma fonte valiosa de informações de eventos de falhas. Quando ocorre um travamento de software, o StarOS captura e armazena dados relevantes que podem ajudar a determinar a causa do travamento. Essas informações podem ser armazenadas na memória do sistema ou transferidas e salvas em um servidor de rede.
Arquivo principal ou Mini arquivo principal: observe que os arquivos principais correspondem aos PIDs onde ocorreu o travamento. Os arquivos principais são nomeados no formato "crash-<card no>-<cpu>-<pid>-<unixtime>-core". Você pode encontrar essas informações na saída do comando "show crash list".
Arquivo Minicore: este arquivo contém informações sobre a tarefa com falha, incluindo o rastreamento de pilha atual, amostras de profiler anteriores, amostras de atividade de memória passadas e outros dados agrupados em um formato de arquivo proprietário.
Dump Principal (ou Core Completo): um dump principal fornece um dump de memória completo do processo imediatamente após a ocorrência do crash. Esse despejo de memória é frequentemente essencial na identificação da causa raiz do travamento do software.
Assinaturas de travamento: as assinaturas de travamento podem ser analisadas no SSD (Show Support Details, detalhes de suporte) compartilhado ou em outras fontes relevantes.
******** 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
Agora, se você quiser saber a assinatura da falha 1, pesquise no SSD com CRASH #01 ou no CLI use 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
Examine o Show Support Details (SSD) e os syslogs durante o carimbo de data/hora específico quando o problema ocorreu.
Etapas da análise
1. É necessário verificar a assinatura/pilha de travamento e se há algum bug para essa assinatura de travamento em particular.
2. É necessário analisar o arquivo central/minicore para analisar o backtrace e obter uma pista de qual função o recurso falhou.
3. Uma vez que a depuração do arquivo de núcleo é feita, você precisa verificar os sintomas com o defeito do software e se há algum defeito existente do software para uma assinatura de travamento e backtrace semelhante.
Recuperação de sessão
O software StarOs foi projetado para lidar com condições/eventos previstos e condições/eventos imprevistos. Enquanto a Cisco se esforça para ter o software perfeito, inevitavelmente existem erros e falhas são possíveis. É por isso que o recurso de recuperação de sessão é tão importante.
O recurso de recuperação de sessão fornece failover e reconstrução perfeitos das informações da sessão do assinante no caso de uma falha de hardware ou software no sistema, impedindo que uma sessão de usuário totalmente conectada seja desconectada. A recuperação de sessão é realizada pelo espelhamento dos principais processos de software (por exemplo, gerenciador de sessão e gerenciador AAA) no sistema. Esses processos espelhados permanecem em um estado ocioso (modo de espera) em que não executam nenhum processamento até que possam ser necessários no caso de uma falha de software (por exemplo, uma tarefa do gerenciador de sessão é anulada).
Tarefas como demux tasks, AAA manager e VPN manager têm mecanismos de recuperação automática incorporados em nossos sistemas, especificamente para lidar com informações de assinantes. A recuperação de sessão se refere principalmente a cenários em que há uma falha na tarefa do sessmgr ou uma falha no nível da placa, e as sessões precisam ser recuperadas sem nenhuma perda de chamada.
- No sistema, um gerenciador de sessão em standby está ativo em cada placa de processamento e pode assumir rapidamente como o gerenciador de sessão primário em caso de falha. Um novo smgr em espera é então criado na placa de processamento.
- Quando um processo do sessmgr falha inesperadamente, o sessmgr em standby recupera informações de backup do aamgr (gerenciador AAA) e reconstrói suas sessões.
- Se o aamgr falhar, o aamgr em espera consultará o sessmgr para sincronizar as informações relevantes do assinante.
- No caso de falha do demux-mgr, ele consulta todos os sessmgrs e reconstrói seu banco de dados de informações de distribuição de chamadas.
-
Para garantir a redundância no nível da placa, uma placa de processamento serve como um standby, pronto para assumir em caso de falha de hardware ou software. A placa em standby recupera as sessões de um peer amgr executado em uma placa diferente.
******** 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
Feedback