Inleiding
Dit document beschrijft hoe u StarOs Facility crashes kunt vinden en oplossen.
Overzicht
Soms kan de systeemlogica mislukken, waardoor een software taak opnieuw moet starten om de juiste functionaliteit te herstellen. Dit kan leiden tot een proces crash. De crashes van de taakfaciliteit worden vaak gerapporteerd in StarOS, en de nodige acties kunnen worden ondernomen op basis van de grondoorzaak van de crash. Om crashes op de node te identificeren, kunt u deze CLI-opdracht gebruiken:
******** 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
Gelijksoortige crashes worden geconsolideerd in één record. De record geeft het aantal keren weer dat dit type crash is opgetreden.
********************* 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 verbosede output toont aan dat één of ander proces is neergestort:
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
Scenario van de crashes
Er kunnen verschillende redenen zijn voor crashes:
1. Verschillende scenario's voor gespreksstromen
2. Geheugenproblemen
3. Probleem met configuratie
4. Hardware-fouten
Reden achter de crash
Je hebt meerdere taakfaciliteiten in StarOS met hun individuele functionaliteit, dus gebaseerd op de functies, wanneer de faciliteit een dergelijke input tegenkomt waar het in een problematische toestand komt, crasht het de faciliteit om te herstellen van die fouttoestand.
Verschillende soorten crash
1. Ontbreken van de verklaring:
********************* 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. Segmenteringsfout:
********************* 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. Fataal signaal:
********************* 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
Eerste logboekvereiste
Het crashlogboek is een waardevolle bron van informatie over crashgebeurtenissen. Wanneer een software crash optreedt, neemt StarOS relevante gegevens op en slaat deze op, die kunnen helpen bij het bepalen van de oorzaak van de crash. Deze informatie kan worden opgeslagen in het systeemgeheugen of worden overgebracht en opgeslagen op een netwerkserver.
Core File of Mini Core File: Merk op dat de kernbestanden corresponderen met de PID(s) waar de crash zich voordeed. Core-bestanden worden genoemd in de indeling "crash-<card no>-<cpu>-<pid>-<unixtime>-core". U vindt deze informatie in de opdrachtoutput "show crash list".
Minicore File: Dit bestand bevat informatie over de falende taak, inclusief de huidige stack-overtrek, oude profiler-monsters, voormalige geheugen-activiteitsmonsters en andere gebundelde gegevens in een eigen bestandsindeling.
Core Dump (of Full Core): een core dump biedt een volledige geheugen dump van het proces direct nadat de crash plaatsvond. Deze geheugendump is vaak essentieel in het identificeren van de basisoorzaak van de software crash.
Crash Signatures: De crash handtekeningen kunnen worden bekeken vanuit de gedeelde Show Support Details (SSD) of andere relevante bronnen.
******** 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
Als u nu de handtekening voor crash 1 wilt weten, zoek dan in SSD met CRASH #01 of in CLI gebruik show crash nummer 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
Bekijk de Show Support Details (SSD) en syslogs tijdens de specifieke tijdstempel toen het probleem zich voordeed.
Analyse stappen
1. Noodzaak om de crashstack/handtekening te controleren en te controleren of er bugs zijn voor die bepaalde crashhandtekening.
2. Moet de corefile/minicore te analyseren de backtrace en om een idee te krijgen van welke functie de faciliteit crashte.
3. Zodra corefile-debugging is uitgevoerd, moet u de symptomen met het softwarestoornis verifiëren en of er een bestaand softwarestoornis is voor een gelijksoortige crashhandtekening en backtrace.
Sessieherstel
StarOs-software is ontworpen om zowel voorziene omstandigheden/gebeurtenissen als onvoorziene omstandigheden/gebeurtenissen te verwerken. Terwijl Cisco ernaar streeft perfecte software te hebben, bestaan er onvermijdelijk fouten en kunnen er crashes optreden. Daarom is de functie voor sessieherstel zo belangrijk.
De functie Sessieherstel biedt naadloze failover en reconstructie van informatie over abonneesessies in het geval van een hardware- of softwarefout in het systeem die verhindert dat een volledig verbonden gebruikerssessie wordt losgekoppeld. Session recovery wordt uitgevoerd door het spiegelen van belangrijke softwareprocessen (bijvoorbeeld Session Manager en AAA Manager) binnen het systeem. Deze gespiegelde processen blijven in een inactiviteitstoestand (stand-by modus) waarin ze geen verwerking uitvoeren tot ze in het geval van een softwarestoring nodig kunnen zijn (bijvoorbeeld een taak voor sessiemanagers wordt afgebroken).
Taken zoals demux-taken, AAA-beheer en VPN-beheer hebben ingebouwde automatische herstelmechanismen in onze systemen, specifiek voor de verwerking van abonneegegevens. Sessieherstel verwijst in de eerste plaats naar scenario's waarbij er een storing is in de sessmgr-taak of een fout op kaartniveau, en sessies moeten worden hersteld zonder gespreksverlies.
- In het systeem is een stand-by sessiemanager actief op elke verwerkingskaart en kan snel overnemen als de primaire sessmgr in het geval van een storing. Vervolgens wordt er een nieuwe stand-by sesmgr gecreëerd op de verwerkingskaart.
- Wanneer een sessmgr-proces onverwacht mislukt, haalt de stand-by sessmgr de back-upinformatie op van de aaamgr (AAA-beheerder) en herbouwt de sessies.
- Als de amgr mislukt, vraagt de standby amgr de sessmgr om de relevante abonneegegevens te synchroniseren.
- In het geval van demux-mgr falen, het alle sessmgrs bevraagt en reconstrueert zijn database van de distributie van oproepen informatie.
-
Om redundantie op kaartniveau te garanderen, dient één verwerkingskaart als stand-by, klaar om over te nemen in het geval van hardware- of softwarestoringen. De stand-by kaart herstelt vervolgens de sessies van een peer-beheerder die op een andere kaart draait.
******** 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