Einleitung
In diesem Dokument wird beschrieben, wie StarOs Facility-Abstürze erkannt und behoben werden.
Überblick
Manchmal kann die Systemlogik fehlschlagen, was dazu führt, dass ein Software-Task neu gestartet wird, um die ordnungsgemäße Funktion wiederherzustellen. Dies kann zu einem Prozessabsturz führen. Abstürze von Aufgabeneinrichtungen werden in StarOS häufig gemeldet, und die erforderlichen Maßnahmen können basierend auf der Ursache des Absturzes ergriffen werden. Um Abstürze auf dem Knoten zu identifizieren, können Sie den folgenden CLI-Befehl verwenden:
******** 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
Ähnliche Abstürze werden in einem Datensatz zusammengefasst. Der Datensatz zeigt an, wie oft dieser Absturztyp aufgetreten ist.
********************* 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 verbosezeigt, dass ein Prozess abgestürzt ist:
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
Szenario der Abstürze
Abstürze können aus verschiedenen Gründen auftreten:
1. Unterschiedliche Anrufflussszenarien
2. Speicherprobleme
3. Konfigurationsproblem
4. Hardwarefehler
Ursache des Absturzes
In StarOS gibt es mehrere Aufgabenbereiche, deren individuelle Funktionalität auf den Funktionen basiert. Wenn eine Einrichtung auf solche Eingaben trifft, bei denen sie in einen problematischen Zustand gerät, stürzt sie die Einrichtung ab, um diesen Fehlerzustand zu beheben.
Verschiedene Arten von Abstürzen
1. Erklärungsfehler:
********************* 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. Segmentierungsfehler:
********************* 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. Schwerwiegendes Signal:
********************* 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
Anfängliche Protokollanforderungen
Das Absturzprotokoll dient als wertvolle Quelle für Informationen über das Absturzereignis. Bei einem Software-Absturz erfasst und speichert StarOS relevante Daten, anhand derer die Ursache des Absturzes ermittelt werden kann. Diese Informationen können im Systemspeicher abgelegt oder auf einem Netzwerkserver übertragen und gespeichert werden.
Core-Datei oder Mini-Core-Datei: Beachten Sie, dass die Core-Dateien den PID(s) entsprechen, in denen der Absturz aufgetreten ist. Core-Dateien werden im Format "Absturz-<Kartennr>-<CPU>-<PID>-<Unixtime>-Core" benannt. Diese Informationen finden Sie in der Befehlsausgabe "show crash list".
Minicore-Datei: Diese Datei enthält Informationen über den ausgefallenen Task, einschließlich der aktuellen Stapelüberwachung, vergangenen Profilerproben, vergangenen Speicheraktivitätsproben und anderen gebündelten Daten in einem proprietären Dateiformat.
Core Dump (oder Full Core): Ein Core Dump stellt ein vollständiges Speicherdump des Prozesses unmittelbar nach dem Absturz bereit. Dieses Speicherabbild ist häufig für die Identifizierung der Ursache des Softwareabsturzes unerlässlich.
Crash Signatures (Absturzsignaturen): Die Absturzsignaturen können von der freigegebenen Show Support Details (SSD) oder anderen relevanten Quellen überprüft werden.
******** 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
Wenn Sie jetzt die Signatur für Absturz 1 kennen möchten, suchen Sie in SSD mit CRASH #01 oder in CLI mit show Absturz 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
Überprüfen Sie die Show Support Details (SSD) und die Syslogs während des spezifischen Zeitstempels, wenn das Problem aufgetreten ist.
Analyseschritte
1. Muss den Crash-Stack/die Crash-Signatur überprüfen und überprüfen, ob Fehler für diese spezielle Crash-Signatur vorliegen.
2. Muss die Core-Datei/Minicore analysieren, um den Backtrace zu analysieren und einen Hinweis darauf zu erhalten, welche Funktion die Einrichtung abgestürzt ist.
3. Sobald das Debuggen von Kerndateien abgeschlossen ist, müssen Sie die Symptome des Softwarefehlers überprüfen und überprüfen, ob ein Softwarefehler für eine ähnliche Absturzsignatur und einen ähnlichen Rücklauf vorhanden ist.
Sitzungswiederherstellung
Die StarOs-Software wurde für die Verarbeitung vorhersehbarer und unvorhergesehener Bedingungen und Ereignisse entwickelt. Cisco strebt zwar eine perfekte Software an, es sind jedoch unweigerlich Fehler und Abstürze möglich. Aus diesem Grund ist die Funktion zur Sitzungswiederherstellung so wichtig.
Die Funktion zur Sitzungswiederherstellung ermöglicht ein nahtloses Failover und die Wiederherstellung von Teilnehmersitzungsinformationen, wenn ein Hardware- oder Softwarefehler im System die Trennung einer vollständig verbundenen Benutzersitzung verhindert. Die Sitzungswiederherstellung erfolgt durch Spiegelung wichtiger Softwareprozesse (z. B. Sitzungsmanager und AAA-Manager) innerhalb des Systems. Diese gespiegelten Prozesse verbleiben in einem Inaktivitätszustand (Standby-Modus), in dem sie keine Verarbeitung durchführen, bis sie bei einem Softwarefehler (z. B. Abbruch einer Session-Manager-Aufgabe) benötigt werden.
Aufgaben wie Demux-Aufgaben, AAA-Manager und VPN-Manager verfügen über integrierte automatische Wiederherstellungsmechanismen in unseren Systemen, insbesondere für den Umgang mit Teilnehmerinformationen. Die Sitzungswiederherstellung bezieht sich in erster Linie auf Szenarien, bei denen ein Fehler in der Sessmgr-Aufgabe oder ein Fehler auf Kartenebene vorliegt und Sitzungen ohne Anrufverlust wiederhergestellt werden müssen.
- Im System ist auf jeder Verarbeitungskarte ein Standby-Sitzungsmanager aktiv, der bei einem Ausfall schnell als primärer Sessmgr übernehmen kann. Anschließend wird ein neuer Standby-Sessmgr auf der Verarbeitungskarte erstellt.
- Wenn ein Sessmgr-Prozess unerwartet fehlschlägt, ruft der Standby-Sessmgr gesicherte Informationen vom aaamgr (AAA-Manager) ab und erstellt seine Sitzungen neu.
- Wenn aaamgr ausfällt, fragt der Standby-aaamgr den sessmgr ab, um die relevanten Teilnehmerinformationen zu synchronisieren.
- Bei einem Ausfall von demux-mgr werden alle Sessmgrs abgefragt und die Datenbank mit den Anrufverteilungsinformationen rekonstruiert.
-
Um Redundanz auf Kartenebene sicherzustellen, dient eine Prozessorkarte als Standby-Karte, die bei einem Hardware- oder Softwareausfall sofort einsatzbereit ist. Die Standby-Karte stellt dann die Sitzungen von einem Peer-Aaamgr wieder her, der auf einer anderen Karte ausgeführt wird.
******** 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