The dmsgtracker client should be used more effectively and in the context of ensuring that the visor reconnects to dmsg if / when it becomes disconnected.
Currently the dmsgtracker-client is only started when running the hypervisor. Perhaps it should start by default regardless of hypervisor interface being served.
As a temporary measure to ensure the visor will be restarted if it loses it's connection to dmsg, a service will be included in the linux packages which checks if the /health of the locally running visor can be fetched over dmsghttp with dmsgcurl by the visor's public key. If it cannot be fetched after a few attempts, this will trigger the visor to be restarted
This can be more effectively and sensibly implemented in the source code itself. At which time this is implemented, the service can be removed from the packages.
1756 describes a situation where the dmsgtracker client is actually needed for `skywire-cli visor info
The dmsgtracker client should be used more effectively and in the context of ensuring that the visor reconnects to dmsg if / when it becomes disconnected.
Currently the dmsgtracker-client is only started when running the hypervisor. Perhaps it should start by default regardless of hypervisor interface being served.
As a temporary measure to ensure the visor will be restarted if it loses it's connection to dmsg, a service will be included in the linux packages which checks if the
/healthof the locally running visor can be fetched over dmsghttp withdmsgcurlby the visor's public key. If it cannot be fetched after a few attempts, this will trigger the visor to be restartedThis can be more effectively and sensibly implemented in the source code itself. At which time this is implemented, the service can be removed from the packages.
1756 describes a situation where the dmsgtracker client is actually needed for `skywire-cli visor info