StatusNode.running is not reset when Start fails, so a later Stop panics on a half-started node

[alexjba]

StatusNode.Start marks the node running before startup can fail, and never rolls back. Stop() then assumes a fully-started node and dereferences fields that were never assigned.

Set, never reset — pkg/backend/node/get_status_node.go:214:

if !n.running.CompareAndSwap(false, true) {
	n.logger.Debug("node is already running")
	return ErrNodeRunning
}
...
return n.startWithDB(config)   // no rollback of n.running on error

Partial construction — in startWithDB, setupRPCClient() runs at :352 and can return early; n.downloader = ipfs.NewDownloader(...) is only reached at :357. So a setupRPCClient failure leaves running == true with downloader, rpcClient, timeSourceSrvc and accountsPublisher all nil.

The panic — Logout gates on IsRunning() (pkg/backend/geth_backend.go:2100), sees true, and calls Stop(). Stop() dereferences without nil guards:

n.timeSourceSrvc.Stop()      // :507
n.accountsPublisher.Close()  // :519
n.rpcClient.Stop()           // :521
n.downloader.Stop()          // :529

n.mediaServer and n.localBackup are nil-guarded; these four are not. On the failure path above, timeSourceSrvc panics first.

Suggested fix. Reset n.running to false when startWithDB returns an error, so IsRunning() reflects reality. Adding nil guards in Stop() treats the symptom — the underlying problem is that running is set before startup completes.

Severity: latent. It needs a start failure followed by a logout, and I have not traced a concrete production trigger — filing so it is recorded rather than because it is known to fire.

Found while reviewing #7676.