Overview of System Logging
SUMMARY This section describes the system log messages that identify the Junos OS process responsible for generating the message and provides a brief description of the operation or error that occurred.
System Log Overview
Junos OS generates system log messages (also called syslog messages) to record events that occur on the device, including the following:
-
Routine operations, such as creation of an Open Shortest Path First (OSPF) protocol adjacency or a user login to the configuration database.
-
Failure and error conditions, such as failure to access a configuration file or unexpected closure of a connection to a peer process.
-
Emergency or critical conditions, such as power-down of the device due to excessive temperature.
Each system log message identifies the Junos OS process responsible for generating the message and provides a brief description of the operation or error that occurred. For detailed information about specific system log messages, see the System Log Explorer.
To configure the device to log system messages, configure the syslog statement at the [edit system] hierarchy level.
This topic describes system log messages for Junos OS processes and libraries and not the system logging services on a Physical Interface Card (PIC) such as the Adaptive Services PIC.
Use the System Log Explorer application to view or compare system log messages in different releases.
Starting in Junos OS Release 22.1R1 on SRX Series and NFX Series devices and Junos OS
Evolved Release 22.2R1 on QFX5130, QFX5200, QFX5220, and QFX5700 devices, we’ve added
multiple events inside the event tag using the
<event>UI_LOGIN_EVENT|UI_LOGOUT_EVENT</event>
format,
which has an option (|
) to separate the events and to generate system
log messages. Earlier to these releases, the event tag used the
<event>UI_LOGIN_EVENT UI_LOGOUT_EVENT</event>
format
and for various combinations of <get-syslog-events> rpc
filters
was not getting logged.
System Logging in Junos OS Evolved
In Junos OS Evolved, each node has the standard journalctl
tool,
which is an interface to retrieve and filter the system journal. System log messages
are extracted from the system journal. The relay-eventd
process
runs on all nodes and retrieves events (based on the syslog configuration) from the
system journal as well as error messages from the different applications and
forwards them to the master-eventd
process. The
master-eventd
process runs on the primary Routing Engine and
writes the log messages and errors to disk.
In Junos OS Evolved there is no messages
file on the backup Routing
Engine. All backup Routing Engine logs are in the messages
file on
the primary Routing Engine node.
By default, Junos OS Evolved appends the node name to the hostname in system log messages; Junos OS does not. This action keeps Junos OS Evolved system log messages compliant with RFC5424. However, some monitoring systems may not identify a Junos OS Evolved hostname correctly, because the hostname-node name combination does not match any hostnames in the inventory of hostnames.
Starting in Junos OS Evolved Release 20.4R2, to ensure accurate identification of
Junos OS Evolved hostnames in your monitoring system, use the set system
syslog alternate-format
configuration mode command. This command
changes the format of the Junos OS Evolved system log messages. The node name is
prepended to the process name in the message rather than appended to the hostname,
thereby allowing the monitoring system to identify the hostname correctly.
For example, Junos OS system log messages do not print the origin process in system log messages coming from an FPC:
user@mxhost> show log messages Dec 19 13:22:41.959 mxhost chassisd[5290]: CHASSISD_IFDEV_DETACH_FPC: ifdev_detach_fpc(0) Dec 19 13:23:22.900 mxhost fpc2 Ukern event counter Sock_tx init delayed
However, Junos OS Evolved messages append the node name to the hostname and do print the origin process for messages coming from a node, including FPCs:
user@ptxhost-re0> show log messages May 25 18:41:05.375 ptxhost-re0 mgd[16201]: UI_CHILD_STATUS: Cleanup child '/usr/sbin/dot1xd', PID 21322, status 0 May 25 18:42:34.632 ptxhost-fpc0 evo-cda-bt[14299]: Register bt.igp_misc.debug.hdr_length_cnt not found May 25 18:42:34.753 ptxhost-fpc1 evo-cda-bt[14427]: HBM: hbm_gf_register_inst May 25 18:47:14.498 ptxhost-re0 ehmd[5598]: SYSTEM_APP_READY: App is ready re0-ehmd
If you have configured the alternate format for Junos OS Evolved system log messages, the same set of system log messages would look like this instead, with the hostname by itself:
user@ptxhost-re0> show log messages May 25 18:41:05.375 ptxhost re0- mgd[16201]: UI_CHILD_STATUS: Cleanup child '/usr/sbin/dot1xd', PID 21322, status 0 May 25 18:42:34.632 ptxhost fpc0- evo-cda-bt[14299]: Register bt.igp_misc.debug.hdr_length_cnt not found May 25 18:42:34.753 ptxhost fpc1- evo-cda-bt[14427]: HBM: hbm_gf_register_inst May 25 18:47:14.498 ptxhost re0- ehmd[5598]: SYSTEM_APP_READY: App is ready re0-ehmd
System Logging Facilities and Message Severity Levels
Table 1 lists the Junos
OS system logging facilities that you can specify in configuration
statements at the [edit system syslog]
hierarchy level.
Facility (number) |
Type of Event or Error |
---|---|
|
The Junos OS kernel performs actions and encounters errors. |
|
User-space perform actions or encounter errors. |
|
System perform actions or encounter errors. |
|
Authentication and authorization attempts. |
|
FTP performs actions or encounters errors. |
|
Network Time Protocol performs actions or encounters errors. |
|
Security related events or errors. |
|
Events related to dynamic flow capture. |
|
The local external applications perform actions or encounter errors. |
|
The firewall filter performs packet filtering actions. |
|
The Packet Forwarding Engine performs actions or encounters errors. |
|
Specified configuration is invalid on the router type. |
|
Changes to the Junos OS configuration. |
|
A client application such as a Junos XML protocol or NETCONF XML client issues commands at the Junos OS command-line interface (CLI) prompt. |
Table 2
lists the severity levels that you can specify in configuration statements at the
[edit system syslog]
hierarchy level. The levels from
emergency
through info
are in the order from
highest severity (greatest effect on functioning) to lowest.
Unlike the other severity levels, the none
level disables logging of a facility instead of indicating how seriously
a triggering event affects routing functions. For more information,
see Disabling the System Logging of a Facility.
Value |
Severity Level |
Description |
---|---|---|
N/A |
|
Disables logging of the associated facility to a destination. |
0 |
|
System panic or other condition that causes the router to stop functioning. |
1 |
|
Conditions that require immediate correction, such as a corrupted system database. |
2 |
|
Critical conditions, such as hard errors. |
3 |
|
Error conditions that generally have less serious consequences than errors at the emergency, alert, and critical levels. |
4 |
|
Conditions that warrant monitoring. |
5 |
|
Conditions that are not errors but might warrant special handling. |
6 |
|
Events or non-error conditions of interest. |
7 |
|
Includes all severity levels. |
Default System Log Settings
Table 3 summarizes the default system log settings that apply to all routers that run the Junos OS and specifies which statement to include in the configuration to override the default value.
Setting |
Default |
Overriding Statement |
Instructions |
---|---|---|---|
Alternative facility for message forwarded to a remote machine |
For For For For For For |
[edit system syslog] host hostname { facility-override facility; } |
Changing the Alternative Facility Name for System Log Messages Directed to a Remote Destination |
Format of messages logged to a file |
Standard Junos OS format, based on UNIX format |
[edit system syslog] file filename { structured-data; } |
|
Maximum number of files in the archived set |
10 |
[edit system syslog] archive { files number; } file filename { archive { files number; } } |
|
Maximum size of the log file |
M Series, MX Series, and T Series: 1 megabyte (MB) TX Matrix: 10 MB |
[edit system syslog] archive { size size; } file filename { archive { size size; } } |
|
Timestamp format |
Month, date, hour, minute, second For example: |
[edit system syslog] time-format format; |
|
Users who can read log files |
|
[edit system syslog] archive { world-readable; } file filename { archive { world-readable; } } |
System Logging and Routing Instances
The system log (syslog) client is completely VRF
aware. If a server is reachable through a virtual routing and forwarding (VRF) instance, the
syslog client can send log messages to the server. To specify the routing instance through
which the remote server is reachable, use the routing-instance
statement
(introduced at appropriate hierarchies).
By default, system logging traffic is sent from the management interface on your device and
its associated routing instance. You can configure system logging messages to use the
non-default management routing instance mgmt_junos
.
Benefits of the Dedicated Management Instance
-
Improved security
-
System log traffic no longer has to share a routing table with other control traffic or protocol traffic
-
Easier to use the management interface to troubleshoot
System Logging in the Dedicated Management Instance
In Junos OS Evolved,
system logging uses the mgmt_junos
VRF instance by default as soon as you
configure the management-instance
statement. You do not need to configure
the mgmt_junos
VRF instance for system logging.
Prior to Junos OS Release 24.2R1, system log traffic uses the dedicated management instance
by default when the management-instance
statement is configured, even if
you do not specifically configure mgmt_junos
. Starting in Junos OS Release
24.2R1, you must configure the mgmt_junos
statement for system log traffic
to use the dedicated management instance.
The routing instance that system log traffic uses depends on which routing instances are
configured. System logging traffic prioritizes routing instances configured with the
routing-instance
statement at the [edit system syslog host
ip-address]
hierarchy level, then those configured at the
[edit system syslog]
level. If no routing instance is configured at
either hierarchy, even if the management instance is configured at the global level, the
system logging traffic defaults to the default routing instance and the inet.0 routing
table. Thus, system logs will only reach the host if the host is reachable by the default
inet.0 routing instance.
This behavior is summarized in the table below:
Configured at |
Configured at |
Routing instance system logging traffic uses |
---|---|---|
|
User-defined routing instance |
|
User-defined routing instance |
User-defined routing instance |
The instance configured at the |
None |
mgmt_junos |
mgmt_junos |
None |
User-defined routing instance |
The instance configured at the |
None |
None |
Default routing instance inet.0 |
See Also
Platform-Specific Default System Log Messages
The following messages are generated by default on specific routers. To view any of these types of messages, you must configure at least one destination for messages as described in Junos OS Minimum System Logging Configuration.
To log the kernel process message on an M Series, MX Series, or T Series router, include the
kernel info
statement at the appropriate hierarchy level:[edit system syslog] (console | file filename | host destination | user username) { kernel info; }
On a routing matrix composed of a TX Matrix router and T640 routers, the primary Routing Engine on each T640 router forwards all messages with a severity of
info
and higher to the primary Routing Engine on the TX Matrix router. This is equivalent to the following configuration statement included on the TX Matrix router:[edit system syslog] host scc-master { any info; }
Starting in Junos OS Release 15.1X49-D10 and Junos OS Release 17.3R1, likewise on a routing matrix composed of a TX Matrix Plus router with connected T1600 or T4000 routers, the primary Routing Engine on each T1600 or T4000 LCC forwards to the primary Routing Engine on the TX Matrix Plus router all messages with a severity of
info
and higher. This is equivalent to the following configuration statement included on the TX Matrix Plus router:Note:From the perspective of the user interface, the routing matrix appears as a single router. The TX Matrix Plus router controls all the T1600 or T4000 routers connected to it in the routing matrix.
[edit system syslog] host sfc0-master { any info; }
Interpret Messages Generated in Standard Format
The syntax of a standard-format message generated by a Junos OS process or subroutine library depends on whether it includes the below priority informations:
When the
explicit-priority
statement is included at the [filename] or [hostname] hierarchy level, a system log message has the following syntax:timestamp message-source: %facility–severity–TAG: message-text
When directed to the console or to users, or when the
explicit-priority
statement is not included for files or remote hosts, a system log message has the following syntax:timestamp message-source: TAG: message-text
Table 5 describes the message fields.
Field | Description |
---|---|
timestamp |
Time at which the message was logged. |
message-source |
Identifier of the process or component that generates the message and the routing platform on
which the message was logged. For Junos OS, this field includes two
or more subfields: hostname, process and process ID (PID). For Junos
OS Evolved, this field includes a hostname with an appended node
name, a process name, and PID. If the
hostname process[process-ID] |
facility |
Code that specifies the facility to which the system log message belongs. For a mapping of codes to facility names, see Table: Facility Codes Reported in Priority Information in Including Priority Information in System Log Messages. |
severity |
Numerical code that represents the severity level assigned to the system log message. For a mapping of codes to severity names, see Table: Numerical Codes for Severity Levels Reported in Priority Information in Including Priority Information in System Log Messages. |
TAG |
Text string that uniquely identifies the message, in all uppercase letters and using the underscore (_) to separate words. The tag name begins with a prefix that indicates the generating software process or library. The entries in this reference are ordered alphabetically by this prefix. Not all processes on a routing platform use tags, so this field does not always appear. |
message-text |
Text of the message. |
Interpret Messages Generated in Standard Format by a Junos OS Process or Library
The syntax of a standard-format message generated by a Junos OS process or subroutine library depends on whether it includes priority information:
-
When the
explicit-priority
statement is included at the [edit system syslog file
filename] or [edit system syslog host
(hostname | other-routing-engine)] hierarchy level, a system log message has the following syntaxtimestamp message-source:
%facility–severity–TAG
: message-text -
When directed to the console or to users, or when the explicit-priority statement is not included for files or remote hosts, a system log message has the following syntax:
timestamp message-source:
TAG
: message-text
Table 6 describes the message fields.
Field | Description |
---|---|
timestamp | Time at which the message was logged. |
message-source | Identifier of the process or component that generated the message and the routing platform on which the message was logged. This field includes two or more subfields, depending on how system logging is configured. See The message-source Field on a TX Matrix Platform,The message-source Field on a T640 Routing Node in a Routing Matrix, and The message-source Field on a Single-Chassis System. |
facility | Code that specifies the facility to which the system log message belongs. For a mapping of codes to facility names, see Table: Numerical Codes for Severity Levels Reported in Priority Information in Including Priority Information in System Log Messages. |
severity | Numerical code that represents the severity level assigned to the system log message. For a mapping of codes to severity names, see Table: Numerical Codes for Severity Levels Reported in Priority Information in Including Priority Information in System Log Messages. |
TAG |
Text string that uniquely identifies the message, in all uppercase letters and using the underscore (_) to separate words. The tag name begins with a prefix that indicates the generating software process or library. The entries in this reference are ordered alphabetically by this prefix. Not all processes on a routing platform use tags, so this field does not always appear. |
message-text | Text of the message. For the text for each message, see the chapters following System Log Messages. |
Interpret Messages Generated in Standard Format by Services on a PIC
Standard-format system log messages generated by services on a PIC, such as the Adaptive Services (AS) PIC, have the following syntax:
timestamp
(FPC Slot
fpc-slot,PIC Slot
pic-slot) {service-set} [SERVICE]: optional-stringTAG
: message-text
System logging for services on PICs is not configured at the [edit system
syslog
] hierarchy level as discussed in this chapter. For configuration
information, see the Junos Services Interfaces Configuration Guide.
The (FPC Slot fpc-slot, PIC Slot pic-slot) field appears only when the standard system logging utility that runs on the Routing Engine writes the messages to the system log. When the PIC writes the message directly, the field does not appear.
Table 7 describes the message fields.
Field | Description |
---|---|
timestamp | Time at which the message was logged. |
fpc-slot | Slot number of the Flexible PIC Concentrator (FPC) that houses the PIC that generated the message. |
pic-slot | Number of the PIC slot on the FPC in which the PIC that generated the message resides. |
service-set | Name of the service set that generated the message. |
SERVICE |
Code representing the service that generated the message. The codes include the following:
|
optional-string | A text string that appears if the configuration for the PIC includes the log-prefix statement at the [edit interfaces interface-name services-options syslog] hierarchy level. For more information, see the Junos Services Interfaces Configuration Guide. |
TAG | Text string that uniquely identifies the message, in all uppercase letters and using the underscore (_) to separate words. The tag name begins with a prefix that indicates the generating PIC. The entries in this reference are ordered alphabetically by this prefix. |
message-text | Text of the message. For the text of each message, see System Log Messages. |
Interpret Messages Generated in Structured-Data Format
Beginning in Junos OS Release 8.3, when the structured-data statement is included in the configuration for a log file, Junos OS processes and software libraries write messages to the file in structured-data format instead of the standard Junos OS format. For information about the structured-data statement, see Logging Messages in Structured-Data Format.
Structured-format makes it easier for automated applications to extract information from the message. In particular, the standardized format for reporting the value of variables (elements in the English-language message that vary depending on the circumstances that triggered the message) makes it easy for an application to extract those values. In standard format, the variables are interspersed in the message text and not identified as variables.
The structured-data format for a message includes the following fields (which appear here on two lines only for legibility):
<priority code>version timestamp hostname process processID TAG [junos@2636.platform variable-value-pairs] message-text
Table 8 describes the fields. If the system logging utility cannot determine the value in a particular field, a hyphen ( - ) appears instead.
Field | Description | Examples |
---|---|---|
<priority code> | Number that indicates the message’s facility and severity. It is calculated by multiplying the facility number by 8 and then adding the numerical value of the severity. For a mapping of the numerical codes to facility and severity, see Table: Facility and Severity Codes in the priority-code Field in Specifying the Facility and Severity of Messages to Include in the Log. | <165> for a message from the pfe facility (facility=20) with severity notice (severity=5). |
version | Version of the Internet Engineering Task Force (IETF) system logging protocol specification. | 1 for the initial version |
timestamp |
Time when the message was generated, in one of two representations:
|
2007-02-15T09:17:15.719Z is 9:17 AM UTC on 15 February 2007. 2007-02-15T01:17:15.719 -08:00 is the same timestamp expressed as Pacific Standard Time in the United States. |
hostname | Name of the host that originally generated the message. | router1 |
process | Name of the Junos OS process that generated the message. | mgd |
processID | UNIX process ID (PID) of the Junos OS process that generated the message. | 3046 |
TAG | Junos OS system log message tag, which uniquely identifies the message. | UI_DBASE_LOGOUT_EVENT |
junos@2636.platform | An identifier for the type of hardware platform that generated the message. The junos@2636 prefix indicates that the platform runs Junos OS. It is followed by a dot-separated numerical identifier for the platform type. For a list of the identifiers, see Table 10. | junos@2636.1.1.1.2.18 for the M120 router |
variable-value-pairs | A variable-value pair for each element in the message-text string that varies depending on the circumstances that triggered the message. Each pair appears in the format variable = "value". | username="user" |
message-text | English-language description of the event or error (omitted if the brief statement is included at the [edit system syslog file filename structured-data] hierarchy level). For the text for each message, see the chapters following System Log Messages. | User 'user' exiting configuration mode |
By default, the structured-data version of a message includes English text at the end, as in the following example (which appears on multiple lines only for legibility):
<165>1 2007-02-15T09:17:15.719Z router1 mgd 3046 UI_DBASE_LOGOUT_EVENT [junos@2636.1.1.1.2.18 username="user"] User 'user' exiting configuration mode
When the brief statement is included at the [edit system syslog file filename structured-data ] hierarchy level, the English text is omitted, as in this example:
<165>1 2007-02-15T09:17:15.719Z router1 mgd 3046 UI_DBASE_LOGOUT_EVENT [junos@2636.1.1.1.2.18 username="user"]
Table 9 maps the codes that appear in the priority-code field to facility and severity level.
Not all of the facilities and severities listed in Table 9 can be included in statements at the [edit system syslog] hierarchy level (some are used by internal processes). For a list of the facilities and severity levels that can be included in the configuration, see Specifying the Facility and Severity of Messages to Include in the Log.
Facility (number) | Severity emergency | alert | critical | error | warning | notice | info | debug |
---|---|---|---|---|---|---|---|---|
kernel (0) | 1 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
user (1) | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
mail (2) | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |
daemon (3) | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
authorization (4) | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 |
syslog (5) | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 |
printer (6) | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 |
news (7) | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 |
uucp (8) | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 |
clock (9) | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 |
authorization-private (10) | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 |
ftp (11) | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 |
ntp (12) | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 |
security (13) | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 |
console (14) | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 |
local0 (16) | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 |
dfc (17) | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 |
local2 (18) | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 |
firewall (19) | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 |
pfe (20) | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 |
conflict-log (21) | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 |
change-log (22) | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 |
interactive-commands (23) | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 |
Table 10 lists the numerical identifiers for routing platforms that appear in the platform field. The identifier is derived from the platform’s SNMP object identifier (OID) as defined in the Juniper Networks routing platform MIB. For more information about OIDs, see the Network Management and Monitoring Guide.
Identifier | Platform Name |
---|---|
1.1.1.2.1 | M40 router |
1.1.1.2.2 | M20 router |
1.1.1.2.3 | M160 router |
1.1.1.2.4 | M10 router |
1.1.1.2.5 | M5 router |
1.1.1.2.6 | T640 routing node |
1.1.1.2.7 | T320 router |
1.1.1.2.8 | M40e router |
1.1.1.2.9 | M320 router |
1.1.1.2.10 | M7i router |
1.1.1.2.11 | M10i router |
1.1.1.2.13 | J2300 Services Router |
1.1.1.2.14 | J4300 Services Router |
1.1.1.2.15 | J6300 Services Router |
1.1.1.2.17 | TX Matrix platform |
1.1.1.2.18 | M120 router |
1.1.1.2.19 | J4350 Services Router |
1.1.1.2.20 | J6350 Services Router |
1.1.1.2.23 | J2320 Services Router |
1.1.1.2.24 | J2350 Services Router |
1.1.1.2.27 | T1600 router |
1.1.1.2.37 | TX Matrix Plus platform |
1.1.1.2.83 | T4000 router |
Manage Host OS System Log and Core Files
On Junos OS switches with a host OS, the Junos OS might generates system log messages (also called syslog messages) to record events that occur on the switch, including the following:
Routine operations, such as a user login into the configuration database.
Failure and error conditions.
Emergency or critical conditions, such as power-down of the switch due to excessive temperature.
On OCX Series switches:
System log messages are logged in the /var/log/dcpfe.log file in the host OS in the following scenarios:
When the forwarding daemon is initialized.
Messages are tagged as emergency (LOG_EMERG). A copy of the message is also sent to the /var/log directory on the switch.
Messages from processes are available on the host system in the /var/log directory. System log messages from the host chassis management process are recorded in the lcmd.log file in the /var/log directory.
On QFX switches with a host OS:
The Junos OS and host OS record log messages for system and process events, and generate core files upon certain system failures.
These files are stored in directories such as /var/log for log messages, and /var/tmp or /var/crash for core files, depending on the type of host OS running on the switch.
For diagnostic purposes, you can access these host OS system log and core files from the Junos OS CLI on the switch. You can also clean up directories where the host OS stores temporary log and other files.
This topic includes these sections:
- View Log Files On the Host OS System
- Copy Log Files From the Host System To the Switch
- View Core Files On the Host OS System
- Copy Core Files From the Host System To the Switch
- Clean Up Temporary Files on the Host OS
View Log Files On the Host OS System
To view a list of the log files created on the host OS, enter the following command:
user@switch> show app-engine logs
Copy Log Files From the Host System To the Switch
To copy log files from the host OS to the switch, enter the following command:
user@switch> request app-engine file-copy log from-jhost source to-vjunos destination
For example, to copy the lcmd log file to the switch, enter the following command:
user@switch> request app-engine file-copy log from-jhost lcmd.log to-vjunos /var/tmp
View Core Files On the Host OS System
To view the list of core files generated and stored on the host OS system, enter the following command:
user@switch> show app-engine crash
The list might look like this example output:
Compute cluster: default-cluster Compute node: default-node Crash Info ========== total 13480 -rw-r--r-- 1 root root 178046 Feb 14 23:08 localhost.lcmd.26653.1455520135.core.tgz -rw-r--r-- 1 root root 4330343 Feb 15 00:45 localhost.dcpfe.7155.1455525926.core.tgz -rw-r--r-- 1 root root 4285901 Feb 15 01:49 localhost.dcpfe.25876.1455529782.core.tgz -rw-r--r-- 1 root root 4288508 Feb 15 02:39 localhost.dcpfe.713.1455532774.core.tgz -rw-r--r-- 1 root root 264079 Feb 15 17:02 localhost.lcmd.1144.1455584540.core.tgz
Copy Core Files From the Host System To the Switch
To copy core files from the host OS to the switch, enter the following command:
user@switch> request app-engine file-copy crash from-jhost source to-vjunos destination-dir-or-file-path
When the destination Junos OS path is a directory, the source filename is used by default. To rename the file at the destination, enter the destination argument as a full path including the desired filename.
For example, to copy the localhost.lcmd.26653.1455520135.core.tgz core archive file to the switch, enter the following command:
user@switch> request app-engine file-copy crash from-jhost localhost.lcmd.26653.1455520135.core.tgz to-vjunos /var/tmp
To see the results on the switch, enter the following command:
user@switch> show system core-dumps re0: -------------------------------------------------------------------------- -rw-r--r-- 1 root field 178046 Feb 15 17:15 /var/tmp/localhost.lcmd.26653.1455520135.core.tgz total files: 1
Clean Up Temporary Files on the Host OS
To remove temporary files created on the host OS, enter the following command:
user@switch> request app-engine cleanup
For example, the following sample output on a switch with a Linux host OS shows cleanup of temporary files stored in /var/tmp:
Compute cluster: default-cluster Compute node: default-node Cleanup (/var/tmp) =======
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
management-instance
statement, the
server was reachable through that VRF instance but the
syslog client could not send syslog messages to the
server.info
and higher.