A customer has reported an unexplained reboot of an ONTAP node that did not generate a panic string or a core file. In this scenario, which two sets…

When an ONTAP node reboots without generating a core file or a panic string, the cause is typically not a standard ONTAP software panic. The investigation must focus on hardware-level events or externally initiated reboots. The detailed Service Processor (SP) logs, accessed via sp status -d, are critical as the SP operates independently of ONTAP and records low-level hardware events, environmental alerts, power cycles, and console activity. The system-level event logs, collected with events all, provide a chronological timeline of ONTAP software events, which can reveal warnings or activities that occurred immediately before the unexpected shutdown, helping to correlate events and determine the root cause.

A. system core: The scenario explicitly states that a core file was not generated, so this log is unavailable for collection and analysis.

B. sp status: This command provides only a high-level summary of the SP's status and is insufficient for the detailed forensic analysis required to diagnose an unexplained reboot.

1. NetApp ONTAP 9 Documentation - system service-processor show command: The sp status -d command is the 7-Mode equivalent of the clustered ONTAP command system service-processor show -instance. The documentation for this command family states that it displays detailed information from the Service Processor

including the SP event logs which contain "a log of boot progress

and other SP events that can be useful for troubleshooting." This is the primary source for hardware-level event data when a core file is absent.

Source: NetApp ONTAP 9 Commands: Manual Page Reference

system service-processor show section.

2. NetApp ONTAP 9 Documentation - Event Management: The events all command (or its modern equivalent event log show) is used to display messages from the Event Management System (EMS). The System Administration Guide for ONTAP explains that EMS provides a centralized

time-stamped log of all system events. This is essential for "reconstructing the sequence of events that led to a failure

" which is precisely the goal in this scenario.

Source: NetApp ONTAP 9 System Administration Guide

"Event management overview" section.

3. NetApp Knowledge Base - Troubleshooting Unplanned Reboots: Official NetApp troubleshooting procedures for unplanned reboots consistently instruct support engineers and administrators to collect both the EMS logs and the Service Processor logs as the first step

especially when no core dump is present. The SP logs are cited as the source for identifying the reboot reason (e.g.

"Reboot due to panic

" "Reboot due to watchdog timeout

" "Reboot due to power-cycle").

Source: NetApp KB Article 1030233

"How to troubleshoot a node reboot". (Note: Access to NetApp's support site may be required). This article outlines the standard data collection procedure

prioritizing SP and EMS logs in the absence of a core file.