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
