You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've seen situations, when remote host went offline, but autossh containers remained with dangling ssh connection, which is neither online nor offline. Eventually, autossh restarts them, perhaps when some port lease expires within the kernel. But it takes time, about 30 minutes.
Monitor port is disabled by -M 0, but is actually useful for resuming connection that is stalled due to an issue described above.
Enabling monitor port isn't easy, because it is hardcoded in autossh:
char*mhost="127.0.0.1"; /* host in port forwards */
...
/* * Only if we're doing the network monitor thing. * Socket once opened stays open for listening for * the duration of the program. */if (writep) {
if (!echop) {
sock=conn_listen(mhost, readp);
/* set close-on-exec */
(void)fcntl(sock, F_SETFD, FD_CLOEXEC);
} elsesock=NO_RD_SOCK;
}
As we know, assumption of 127.0.0.1 being a loopback address is wrong in Docker. Should we [ask for a] patch autossh source code, or do you see some other workaround?
The text was updated successfully, but these errors were encountered:
I've seen situations, when remote host went offline, but autossh containers remained with dangling ssh connection, which is neither online nor offline. Eventually, autossh restarts them, perhaps when some port lease expires within the kernel. But it takes time, about 30 minutes.
Monitor port is disabled by
-M 0
, but is actually useful for resuming connection that is stalled due to an issue described above.Enabling monitor port isn't easy, because it is hardcoded in autossh:
As we know, assumption of 127.0.0.1 being a loopback address is wrong in Docker. Should we [ask for a] patch autossh source code, or do you see some other workaround?
The text was updated successfully, but these errors were encountered: