It's my understanding that the miner config (sys.config) is pre-populated at intervals with the latest snapshot info from hm-block-tracker. It appears that when the fast-sync server is down it causes the miner to crash on boot, even if it does not need to use it (for example after a crash / reboot).
If the /latest-snapshot.json endpoint returns an error such as '{"height": 'miner@127.0.0.1', "hash": ""}', which it has been doing more frequently recently, the miner cannot boot.
There is a helium config value, fetch_latest_from_snap_source which is set to true (both by default and in your config) - but I believe it might actually be redundant and counter-productive to have enabled as the snapshot info in the config is always in date anyway. I suggest disabling this and it would mean that in the event of a block-tracker crash/error that the older snapshot info can still be used and miners will boot (the cache/block data is still accessible when the /latest-snapshot.json is down).
It's my understanding that the miner config (sys.config) is pre-populated at intervals with the latest snapshot info from hm-block-tracker. It appears that when the fast-sync server is down it causes the miner to crash on boot, even if it does not need to use it (for example after a crash / reboot).
If the /latest-snapshot.json endpoint returns an error such as '{"height": 'miner@127.0.0.1', "hash": ""}', which it has been doing more frequently recently, the miner cannot boot.
There is a helium config value, fetch_latest_from_snap_source which is set to true (both by default and in your config) - but I believe it might actually be redundant and counter-productive to have enabled as the snapshot info in the config is always in date anyway. I suggest disabling this and it would mean that in the event of a block-tracker crash/error that the older snapshot info can still be used and miners will boot (the cache/block data is still accessible when the /latest-snapshot.json is down).