Hypervisor becomes unresponsive when visor dmsgpty connection is interrupted

[0pcom]

While attempting to troubleshoot the issue of potential IP conflicts with skybian, I was working to reproduce the wrongly configured state and so was switching some visors away from the current hypervisor to one of the other visors connected to the hypervisor via the dmsgpty UI terminal for that visor

The procedure for this is to simply run

skywire-autoconfig <new-hypervisor-public-key>

the script will defer the restarting of the process to the user at that point; the user is prompted to run:

systemctl restart skywire 2> /dev/null

What actually happens a this point is that the whole hypervisor ui becomes unresponsive

Jul 25 12:15:05 orangepiprime skywire[1392]: [2022-07-25T12:15:05Z] WARN getVisors [hypervisor]: Failed to obtain summary via RPC.02a915069601423b502a80284d7477fcc3c8c5d7331d29363daf7b306075721a36 RequestID="orangepiprime/Y02qWMJ9qf-000227" error="connection is shut down" visor_addr=02a915069601423b502a80284d7477fcc3c8c5d7331d29363daf7b306075721a36:49153
Jul 25 12:15:11 orangepiprime skywire[1392]: [2022-07-25T12:15:11Z] WARN getVisors [hypervisor]: Failed to obtain summary via RPC.02a915069601423b502a80284d7477fcc3c8c5d7331d29363daf7b306075721a36 RequestID="orangepiprime/Y02qWMJ9qf-000228" error="connection is shut down" visor_addr=02a915069601423b502a80284d7477fcc3c8c5d7331d29363daf7b306075721a36:49153

and so on..

The only quick solution for the user at that point is to restart the hypervisor board.

I suspect that it is the fact that the connection is being terminated during the dmsgpty session which is actually being used.

a rather inconvenient workaround for this is to recommend only access the visors via ssh session from the current hypervisor dmsgpty UI

[0pcom]

fixed with #1323