Re: [Savannah-users] VCS problems

[Phillip Lord]

Okay, thanks for the detailed explanation. I noticed from the archives
that there had been some problem previously, and was worried it might be
a hangover from that.

Perhaps git needs putting on its own machine.

Phil

Bob Proulx <address@hidden> writes:

> 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