Right now Check-Oracle detects "oracle loaded but not running" and tells the operator to check startoracle, but it doesn't diagnose WHY it stopped or warn about the two post-reboot gotchas that actually bite people. Watching operators troubleshoot on mainnet this week (one node stuck mid-reindex reading far below the tip, plus discussion of what a hard reboot does to a running oracle) made clear the alert could carry the fix instead of just flagging the symptom.
Two additions to the not-running path:
-
Wallet-locked detection. When the oracle is loaded but not running on mainnet, call getwalletinfo and check unlocked_until. If the wallet is locked (unlocked_until == 0), the alert should say so plainly ("Wallet is LOCKED, likely after a reboot") and put the actual fix in the message body: walletpassphrase then startoracle for this ORACLE_ID. Today the operator gets "check startoracle" with no hint that a locked wallet is the cause.
-
Post-reboot activation-height note. After an unclean shutdown the chainstate can roll back below the DigiDollar activation height, and startoracle errors until the local tip re-crosses that height. The alert (or a runbook note it points to) should explain this so an operator who reboots, runs startoracle, sees the error, and assumes something is broken understands it just needs the node to catch back up. Same root cause as a node that's behind for any reason (reindex, fresh sync): the oracle can't start until the node is caught up past activation.
Both are read-only additions (getwalletinfo is status-only, no key material). Should mirror across all three platforms (Linux, PowerShell, macOS) to keep parity. Credit to the slot-29 operator's ntfy-based monitor (github.com/dgb-tools/oracle-ops) for surfacing the wallet-locked-in-alert pattern.
Version: oracle-monitor.sh v2.5.6
Right now Check-Oracle detects "oracle loaded but not running" and tells the operator to check startoracle, but it doesn't diagnose WHY it stopped or warn about the two post-reboot gotchas that actually bite people. Watching operators troubleshoot on mainnet this week (one node stuck mid-reindex reading far below the tip, plus discussion of what a hard reboot does to a running oracle) made clear the alert could carry the fix instead of just flagging the symptom.
Two additions to the not-running path:
Wallet-locked detection. When the oracle is loaded but not running on mainnet, call getwalletinfo and check unlocked_until. If the wallet is locked (unlocked_until == 0), the alert should say so plainly ("Wallet is LOCKED, likely after a reboot") and put the actual fix in the message body: walletpassphrase then startoracle for this ORACLE_ID. Today the operator gets "check startoracle" with no hint that a locked wallet is the cause.
Post-reboot activation-height note. After an unclean shutdown the chainstate can roll back below the DigiDollar activation height, and startoracle errors until the local tip re-crosses that height. The alert (or a runbook note it points to) should explain this so an operator who reboots, runs startoracle, sees the error, and assumes something is broken understands it just needs the node to catch back up. Same root cause as a node that's behind for any reason (reindex, fresh sync): the oracle can't start until the node is caught up past activation.
Both are read-only additions (getwalletinfo is status-only, no key material). Should mirror across all three platforms (Linux, PowerShell, macOS) to keep parity. Credit to the slot-29 operator's ntfy-based monitor (github.com/dgb-tools/oracle-ops) for surfacing the wallet-locked-in-alert pattern.
Version: oracle-monitor.sh v2.5.6