Re: [Savannah-users] VCS problems

[Bob Proulx]

Phillip Lord wrote:
> git clone git://git.savannah.gnu.org/emacs.git
> Cloning into 'emacs'...
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.

This problem is unfortunately somewhat common from vcs.  The vcs
server is always in a perpetual state of overload.  The above is what
happens when there are too many simultaneous download connections
through xinetd.  The xinetd daemon returns an immediate tcp FIN to the
client closing the connection immediately for the extra connections.
The above is the message the git client returns when it can't open a
connection. It is secondly unfortunate that the git client doesn't
report the failure in a reasonable way.  That last sentence makes it
sound like it is a permissions problem of some sort.

The same problem exists for cvs, svn, hg and bzr too.  All are
launched through xinetd too.  Except git is the most popular version
control system and therefore is usually the one hitting the limits
most often.

I can only suggest retrying at a later time.  A clever shell user
might do something like this repeat-until loop so that it will
automatically retry until successful.

  until git clone git://git.savannah.gnu.org/emacs; do sleep 90; done

> Normal (member) git access is working fine!

Normal member access uses ssh.  There is no limit configured for sshd
connections.  When the system is overloaded due to too many ssh
connections the system simply browns out, melts down, and then dies
completely.  Although most of the time it recovers to normal service
after the wave of clients recedes back to a normal level.

The anonymous git access is typically the more burdensome because
repositories such as emacs are moderately large and all of the users
cloning it are downloading the entire repository causing a large wave
in outbound I/O.  ssh on the other hand tends to be users who have
already downloaded the repository and are doing incremental exchanges
of changesets which are much smaller.  Also the bottleneck seems to be
disk I/O on the vcs server more than it is the network connection.
Just in the last week the FSF did some file system tuning which
improved the server usability by a huge amount.

Bob