system: report why the node last reset - #558
Open
TurkeyMan wants to merge 1 commit into
Open
Conversation
A restart that never reaches the panic handler leaves no core dump, so a brownout, a clean reboot and a watchdog reset are indistinguishable after the fact - the boot banner is gone as soon as the log ring turns over. Platforms that know report it: ESP32 maps esp_reset_reason(). Linux returns null, because the supervisor relaunches the process and the reason it stopped is in the supervisor's log rather than anything the new process can read; the line is omitted when there is nothing to say.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A restart that never reaches the panic handler leaves no core dump, so a brownout, a clean reboot and a watchdog reset are indistinguishable after the fact - the boot banner is gone as soon as the log ring turns over.
Prompted by a live case: an ESP32-S3 was found with an unexplained 5-hour-old restart. Seven core dumps on its filesystem all carried the SHA of older images, which proved the running firmware had never panicked - but left no way to tell what did restart it.
Platforms that know, report it. ESP32 maps
esp_reset_reason()(power-on, external pin, software, panic, interrupt/task/other watchdog, deep-sleep wake, brownout, sdio, usb, jtag). Linux returns null - the supervisor relaunches the process and the reason it stopped lives in the supervisor's log, not in anything the new process can read - and the line is omitted when there is nothing to say.Also readable as
/system/sysinfo reset-reason. Verified on hardware; 139/139 modules pass.🤖 Generated with Claude Code