Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Problem reports for version control systems



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? :-)

-- R


Home | Main Index | Thread Index | Old Index