Morgan Brown asked:
I use a perl script (with the Semaphore package) to fire off long-running ssh commands to AWS instances. For several reasons, I do NOT run the ssh commands in the background.
Recently, the Comcast fiber to our office building was cut by a construction crew. We maintain a backup CenturyLink connection, and our IT people switched our office connection over to CenturyLink.
My ssh processes died with a "timeout, server not responding" message when we switched from Comcast to CenturyLink. They died again when we switched back to Comcast after the fiber was repaired.
Is this expected behavior for an open ssh command if the local public IP address changes? If I put the ssh commands in the background, would it solve this issue?
Yes, that’s expected behavior. Your connection was physically interrupted, after all.
If an interruption in your connection may cause a failure of a long running remote process, consider running it in a
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.