Keeping a node alive
You will be able to make a node survive reboots and crashes, back up the one file that matters, and tell whether it is really participating.
Survival
A node that does not restart itself is a node that will stop.
Run it under a service manager so a crash restarts it and a power cut brings it back — on Linux a systemd unit with `Restart=always` and `enable` set. A node that only runs while somebody is logged in will be down the first time nobody is, and a network of such nodes has availability nobody can rely on.
Illustration to come
Real screen capture of `systemctl status` for a node service showing active (running) and enabled. Real output from a real host.
The file to back up
The keystore passphrase, and nothing else.
The installer generates a passphrase and encrypts the node identity with it. Lose that file and the identity is gone — a new one costs nothing on testnet, but any stake or reputation attached to the old one is not coming back. Copy it somewhere off the machine before you need to. The chain data itself is disposable: a node can always resynchronise.
Illustration to come
Real photograph of a USB stick and a handwritten label on a desk. Domestic and low-tech — the backup nobody regrets making.
Is it participating?
Peers, height, and whether the tip is moving.
Ask the node itself: `vigi_getChainInfo` reports its height and whether the chain checked out, `vigi_getPeers` reports how many peers it is connected to. Height rising and peers above zero is a participating node. Height rising with zero peers means it is mining alone, which is worth knowing.
Illustration to come
Real capture of a curl call to a node RPC returning chain info, on a real node. Real numbers, no invented ones.
Resources
Give it memory headroom, and let it page out.
A node under load wants a little more memory than it usually uses, and a machine with no swap will kill the process rather than slow it down. A soft memory ceiling for the node plus real swap on disk turns a hard failure into a slow minute. This project learned it the way everyone does: with a node that died at three in the morning.
Illustration to come
Real screen capture of a memory or resource graph from a monitoring tool, showing a genuine spike. Real data, not an illustration.
In short
- Run the node as an enabled service with automatic restart, or expect it to be down.
- Back up the keystore passphrase file; the chain data can always be re-downloaded.
- Rising height with peers above zero is the honest test of participation.
- Give it memory headroom and swap: a killed node is worse than a slow one.