@sudhir.j asking them about it, but seeing a lot of
ssh: connect to host tunnel.hightouch.io port 49100: Operation timed out
Which of course causes the VM to restart, wondering if you would know anything about this?
Hmm. Autossh autossh(1): monitor/restart ssh sessions - Linux man page can prevent the VM exiting and restarting (they’ve suggested it in their docs as well — you could install it and run ssh through it) but this probably something I’d raise with Hightouch. Maybe they could give you a port that’s more available and reliable?
Gotcha! Okay I will look into both, waiting to hear what they think about the issue.
Thanks again for all your help, you rock!
Do you get these issues when trying to run a tunnel to Hightouch from a local machine pointed at a local DB as well? We can rule out it being a Fly problem if it behaves differently on your dev machine.
To be honest, I have never tried, I have only simply spun up fly VMs - I can certainly try if we are not able to get to the bottom of the issue.
Will this ever stop restarting / redeploying if the problem persists?
@sudhir.j - yup, the VM eventually stopped restarting and now its “dead”. 
Looks like fly might try to spin it back up, but this will cause outages for periods of time, also Im not sure how the fly vm manager works, will this continue to get restarted / redeployed?
so far autossh is working a lot better, no timeouts, no restarts, will keep you posted.
Update: still getting timeouts, but autossh seems to keep the VM up and healthy.
Yeah, autossh will consider a timeout a non-terminal error and keep it going again and again.
I’m not sure what the policy is on VMs that keep crashing, let me check. But either way autossh should sort that out for you.
Yup that is accurate, we are no longer experiencing restarts.
Would love to know more on what the scheduler parameters are for restart count, reboot count, considered dead, etc.
I’ll put that on my docs todo.
1 Like