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 <[email protected]> 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
