Re: intermittent rsh 'connection refused'

2001-07-13 Thread Larry Jones

Lucas Bergman writes:
> 
> I have a repository that is accessed via rsh on my company's local
> net, which we've been using for about 9 months.  Once in a while,
> though, access is suddenly cut off.  One does 'cvs update', and after
> no output for around thirty seconds, one finally gets error messages:
> 
>   server.foo.com: Connection refused
>   cvs [update aborted]: end of file from server \
> (consult above messages if any)
[...]
> Normally the problem corrects itself within five to as long as sixty
> minutes.  It seems to happen more often when lots of big check-ins are
> happening, and the problem seems to correct itself more slowly if a
> lot of developers are banging on it, but that's pure anecdote, no real
> evidence to back it up.

http://cvshome.org/docs/manual/cvs_21.html#SEC182

See the last paragraph -- it's talking about pserver, but the same thing
can happen with rsh and it sounds like that's your problem.

-Larry Jones

The problem with the future is that it keeps turning into the present.
-- Hobbes

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



intermittent rsh 'connection refused'

2001-07-13 Thread Lucas Bergman

Hi --

I have a repository that is accessed via rsh on my company's local
net, which we've been using for about 9 months.  Once in a while,
though, access is suddenly cut off.  One does 'cvs update', and after
no output for around thirty seconds, one finally gets error messages:

  server.foo.com: Connection refused
  cvs [update aborted]: end of file from server \
(consult above messages if any)

Both client and server are a recent GNU/Linux, and run CVS 1.11.  My
$CVSROOT is ':ext:server.foo.com:/usr/cvsroot', and $CVS_RSH is not
set at all.  Simply doing 'rsh server.foo.com' from the same client
works like it should.  Whenever this happens, all rsh clients are cut
off simultaneously, not just one or a few.

Normally the problem corrects itself within five to as long as sixty
minutes.  It seems to happen more often when lots of big check-ins are
happening, and the problem seems to correct itself more slowly if a
lot of developers are banging on it, but that's pure anecdote, no real
evidence to back it up.

Lucas

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs