Cisco Cisco Packet Data Gateway (PDG)
System Logs
▀ Configuring and Viewing Crash Logs
▄ ASR 5000 System Administration Guide, StarOS Release 16
182
Configuring and Viewing Crash Logs
In the unlikely even of a software crash, the system stores information that could be useful in determining the reason for
the crash. This information can be maintained in system memory or it can be transferred and stored on a network server.
the crash. This information can be maintained in system memory or it can be transferred and stored on a network server.
The system supports the generation of the following two types of logs:
Crash log: Crash logs record all possible information pertaining to a software crash (full core dump). Due to
their size, they can not be stored in system memory. Therefore, these logs are only generated if the system is
configured with a Universal Resource Locator (URL) pointing to a local device or a network server where the
log can be stored.
configured with a Universal Resource Locator (URL) pointing to a local device or a network server where the
log can be stored.
Abridged crash log: Crash event records are automatically generated when a software crash occurs and are
stored in flash memory on management cards. The abridged crash log contains a list crash event records along
with associated dump files. This log allows you to view event records and dump files via CLI commands.
with associated dump files. This log allows you to view event records and dump files via CLI commands.
Crash Logging Architecture
The crash log is a persistent repository of crash event information. Each event is numbered and contains text associated
with a CPU (minicore), NPU or kernel crash. The logged events are recorded into fixed length records and stored in
/flash/crashlog2.
with a CPU (minicore), NPU or kernel crash. The logged events are recorded into fixed length records and stored in
/flash/crashlog2.
Whenever a crash occurs, the following crash information is stored:
1. The event record is stored in /flash/crashlog2 file (the crash log).
2. The associated minicore, NPU or kernel dump file is stored in the /flash/crsh2 directory.
3. A full core dump is stored in a user configured directory.
Important:
The crashlog2 file along with associated minicore, NPU and kernel dumps are automatically
synchronized across redundant management cards (SMC, MIO/UMIO). Full core dumps are not synchronized across
management cards.
management cards.
The following behaviors apply to the crash logging process.
When a crash event arrives on an active management card, the event record is stored in its crashlog2 file along
with the minicore, NPU, or kernel dump file in /flash/crsh2. The crash event and dump file are also
automatically stored in the same locations on the standby management card.
automatically stored in the same locations on the standby management card.
When a crash log entry is deleted via CLI command, it is deleted on both the active and standby management
cards.
When a management card is added or replaced, active and standby cards will automatically synchronize crash
logs and dump files.
When a crash event is received and the crash log file is full, the oldest entry in the crash log and its related dump
file will be replaced with the latest arrived event and dump file on both management cards. Information for a
maximum of 120 crash events can be stored on management cards.
maximum of 120 crash events can be stored on management cards.
Duplicate crash events bump the count of hits in the existing record and update the new record with the old crash
record. Additions to the count use the timestamp for the first time the event happened.