Den 2021-05-02 kl. 15:57, skrev Johnny Billquist:
On 2021-05-02 13:51, Anders Magnusson wrote:
Den 2021-05-02 kl. 13:44, skrev Johnny Billquist:
I suspect what is commonly the problem here is related to the fact
that cvs has such a phase at the beginning where it is scanning
through the file system, which can take quite a while. Some NAT
devices along the path sometimes have timeouts on existing
connections that if no traffic is happening for a while, they are
dropped, even though there hasn't been any FINs on the connection.
So a connection that just don't have any traffic for a while are hit
by this, which is exactly the pattern you have with cvs.
I've seen the same effect on a simple telnet session, where ssh
survives fine. And there it's just that when the connection is idle,
telnet is not creating any traffic at all, while ssh do generate a
bit of traffic even if there is no activity.
So one obvious solution is to use something like ssh as a carries
for the cvs traffic, if possible, or else see if some kind of
keepalives can be enabled on a connection, to defeat NAT and similar
devices which aggressively drop connections on which there is no
traffic for a while.
(Or, of course, if there is a NAT you have control over, you might
be able to change how it behaves...)
This is quite common, yes.
I ususlly add ssh keepalive to ssh_config for all hosts to avoid this
problem (which may occur, as written, when doing cvs update).
And as a "fun" fact. On my 4000/90, it takes about 3h after I start a
cvs update until I actually start having any network traffic... In
total it takes something like 8h to do a cvs update on /usr/src.
(I guess I'm a bit masochistic is still insisting on trying to do
things on my VAXen...)
Have you tried it on the 8650? :-)