Junos Core Dump Analysis: Reading Process Crash Files

A daemon restart on a Junos device is rarely random. When routing-engine processes crash, Junos writes a core file plus a context archive that contains the configuration and the system log at the moment of failure — enough evidence for JTAC (or for you) to identify the triggering command. The trick is knowing where those files land on each Junos flavour, and how to collect them without pushing the router into swap. This article covers core file locations, the commands to list and inspect them, and the safe way to capture the context a case needs.

Where core files are written

• Junos OS — core files are stored in /var/core/re. Process cores and their context archives appear under /var/crash/ and /var/tmp/.
• Junos OS Evolved — a core created during early boot lives in /var/core/re; once the Routing Engine slot is known, Routing Engine cores go to /var/core/re0 or /var/core/re1, and FPC cores to /var/lib/ftp/in/.
• Context archive — by default a crashing process produces a compressed tar file named /var/tmp/process-name.core.core-number.tgz containing the configuration and system log files captured at crash time.

Listing core files

user@host> show system core-dumps
user@host> show system core-dumps detail
user@host> show system core-dumps brief
user@host> show system core-dumps core-file-info
user@host> show system core-dumps /var/crash/name.core.0.tgz detail

The listing includes permissions, link count, owner, group, size, modification date, path and filename — read the timestamp and the process name together, because the sequence gives you the crash chain. A routing protocol process that restarts every few hours and leaves one core file per restart is a different problem from a one-off core at the same minute as a configuration commit.

On dual-Routing-Engine chassis, you can list cores for either RE or both:

user@host> show system core-dumps re0
user@host> show system core-dumps re1
user@host> show system core-dumps both-routing-engines

Correlating a core with the event that caused it

1. Note the core timestamp from show system core-dumps.
2. Read the system log around that timestamp: show log messages | last 200, or grep for the process name.
3. Check whether it matches a configuration change window — a crash a few seconds after a commit points at the commit path, while a crash on a timer points at a background task.
4. Compare against show system processes extensive to see whether the process is stuck restarting or has stabilised.

Collecting support information for a case

The request support information command is the standard evidence bundle: it loops through dozens of show commands and writes the output to a file you can attach to a JTAC case. Run it before clearing logs or cores:

user@host> request support information | save /var/tmp/rsi-$(hostname).txt
user@host> file list /var/tmp/
user@host> file show /var/tmp/rsi.txt | no-more

Where storage is tight, copy the core and context tarball off the device first and only then clean up. Keep at least the newest core per process; deleting evidence is the fastest way to turn a reproducible crash into an unfixable one.

A caution about forcing a core dump

request system core-dumps performs a non-fatal dump without aborting the routing protocol process: the process is forked, a second copy is created, and only the copy is aborted. That design has a cost — the two copies can double the memory footprint of the routing protocol process and push the system into swap, which is why you should only run it on a device with headroom, or during a maintenance window. On platforms with tight RE memory, check show system virtual-memory first.

Cleaning up without losing evidence

user@host> file list /var/crash/
user@host> file delete /var/crash/old.core.0.tgz
user@host> request system storage cleanup
user@host> show system storage

request system storage cleanup removes temporary files including older core material, so treat it as a destructive command and confirm the cores you care about have been copied off the box first.

Practical checklist

• Core file exists but no context tarball — the process crashed early, or the device ran out of space while writing. Free space and watch for a repeat.
• Recurring core of the same daemon — check for a known PR against your Junos version before chasing the configuration.
• Cores only on one RE of a dual-RE chassis — verify the backup RE's version matches and that GRES/NSR is not masking a persistent fault.
• vSRX reporting cores for srxpfe after a reboot or upgrade — a documented artefact on that platform rather than a service-affecting crash.

See also: Junos troubleshooting commands reference, FPC offline and chassis alarm troubleshooting, and MX hardware issues and interface damping.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/system-mgmt-monitoring/topics/topic-map/troubleshooting-system-management.html