当git克隆时，远程端意外挂断

时间：2011-07-27 10:12:14

标签： git

我的git客户端在尝试克隆存储库一段时间后反复失败并出现以下错误。

这可能是什么问题？

注意：我已将我的SSH密钥注册到GIT托管服务提供商

Receiving objects:  13% (1309/10065), 796.00 KiB | 6 KiB/s
fatal: The remote end hung up unexpectedly

37 个答案:

答案 0 :(得分：387)

快速解决方案：

出现这种错误，我通常首先提高postBuffer尺寸：

git config --global http.postBuffer 524288000

（下面的一些评论报告不得不加倍）：

git config --global http.postBuffer 1048576000

更多信息：

来自git config man page，http.postBuffer是关于：

  

将数据发送到远程系统时，智能HTTP传输使用的缓冲区的最大大小（以字节为单位）   对于大于此缓冲区大小的请求，使用HTTP / 1.1和Transfer-Encoding: chunked来避免在本地创建大量包文件。默认值为1 MiB，足以满足大多数请求。

即使是克隆，也会产生影响，在这种情况下，OP Joe报告：

  

[clone]现在正常工作

注意：如果服务器端出现问题，并且服务器使用Git 2.5+（2015年第2季度），则错误消息可能更明确。
请参阅“Git cloning: remote end hung up unexpectedly, tried changing postBuffer but still failing”。

Kulai（in the comments）指出this Atlassian Troubleshooting Git page，其中增加了：

  

Error code 56表示卷曲接收错误为CURLE_RECV_ERROR，这意味着存在一些阻止在克隆过程中接收数据的问题。
  通常，这是由网络设置，防火墙，VPN客户端或在所有数据传输之前终止连接的防病毒引起的。

它还提到了以下环境变量，以帮助调试过程。

# Linux
export GIT_TRACE_PACKET=1
export GIT_TRACE=1
export GIT_CURL_VERBOSE=1

#Windows
set GIT_TRACE_PACKET=1
set GIT_TRACE=1
set GIT_CURL_VERBOSE=1

答案 1 :(得分：17)

http.postBuffer技巧不为我工作。但是：

对于遇到此问题的其他人，可能是GnuTLS的问题。如果您设置了详细模式，您可能会看到基础错误看起来与下面的代码一致。

不幸的是，到目前为止我唯一的解决方案是使用SSH。

我见过一个解决方案elsewhere用OpenSSL而不是GnuTLS编译Git。针对该问题here有一个有效的错误报告。

GIT_CURL_VERBOSE=1 git clone https://github.com/django/django.git

Cloning into 'django'...
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.131... * Connected to github.com (192.30.252.131) port 443 (#0)
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
*    server certificate verification OK
*    common name: github.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: 
*    start date: Mon, 10 Jun 2013 00:00:00 GMT
*    expire date: Wed, 02 Sep 2015 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV CA-1
*    compression: NULL
*    cipher: ARCFOUR-128
*    MAC: SHA1
> GET /django/django.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.8.4
Host: github.com
Accept: */*
Accept-Encoding: gzip

Pragma: no-cache
< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Thu, 10 Oct 2013 03:28:14 GMT

< Content-Type: application/x-git-upload-pack-advertisement
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
< 
* Connection #0 to host github.com left intact
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.131... * connected
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
* SSL re-using session ID
*    server certificate verification OK
*    common name: github.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: 
*    start date: Mon, 10 Jun 2013 00:00:00 GMT
*    expire date: Wed, 02 Sep 2015 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV CA-1
*    compression: NULL
*    cipher: ARCFOUR-128
*    MAC: SHA1
> POST /django/django.git/git-upload-pack HTTP/1.1
User-Agent: git/1.8.4
Host: github.com
Accept-Encoding: gzip

Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Content-Encoding: gzip
Content-Length: 2299
* upload completely sent off: 2299out of 2299 bytes

< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Thu, 10 Oct 2013 03:28:15 GMT

< Content-Type: application/x-git-upload-pack-result
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
< 
remote: Counting objects: 232015, done.
remote: Compressing objects: 100% (65437/65437), done.
* GnuTLS recv error (-9): A TLS packet with unexpected length was received.
* Closing connection #0
error: RPC failed; result=56, HTTP code = 200
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

答案 2 :(得分：7)

与Bitbucket相同的错误。由

修正 
RETURN ru, u, rup, up, rdt, t, childD AS decision

答案 3 :(得分：6)

Obs。：更改http.postBuffer可能还需要为gitlab设置Nginx配置文件，以便通过调整client_max_body_size的值来接受客户端更大的主体大小。

但是，如果您可以访问Gitlab计算机或网络中的计算机，则可以使用git bundle。

  1. 转到源计算机上的git存储库
  2. 运行git bundle create my-repo.bundle --all
  3. 将my-repo.bundle文件传输（例如，使用rsync）到目标计算机
  4. 在目标计算机上，运行git clone my-repo.bundle
  5. git remote set-url origin "path/to/your/repo.git"
  6. git push

    7. 一切顺利！

答案 4 :(得分：4)

使用以下命令后我得到了解决方案：

git repack -a -f -d --window=250 --depth=250

答案 5 :(得分：4)

对于共享带宽，请尝试在负载较小时克隆。否则，请尝试高速连接。如果仍然无法使用，请使用以下命令，

git config --global http.postBuffer 2048M
git config --global http.maxRequestBuffer 1024M
git config --global core.compression 9

git config --global ssh.postBuffer 2048M
git config --global ssh.maxRequestBuffer 1024M

git config --global pack.windowMemory 256m 
git config --global pack.packSizeLimit 256m

然后尝试再次克隆。您可能需要根据可用的内存大小更改这些设置。

答案 6 :(得分：3)

如果您使用的是https，则会收到错误。

我使用https代替http，它解决了我的问题

git config --global https.postBuffer 524288000

答案 7 :(得分：2)

在txtInput.Text = Problems[40]中

将该行添加到文件末尾

/etc/resolv.conf

答案 8 :(得分：2)

对我来说唯一有用的是使用 HTTPS 链接而不是 SSH 链接克隆回购。

答案 9 :(得分：2)

我也有同样的问题。这个问题的原因是Kurtis关于GNUTLS的描述。

如果你有相同的理由并且你的系统是Ubuntu，你可以通过从ppa:git-core/ppa安装最新版本的git来解决这个问题。命令如下。

sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get git

答案 10 :(得分：2)

我遇到了同样的问题， 我用试错法解决了这个问题。我更改了core.compression值，直到它起作用为止。

经过3次尝试，我开始使用“ git config --global core.compression 1”

“ git config --global core.compression 4”对我有用。

答案 11 :(得分：2)

在从弹性beanstalk管理的AWS EC2实例上托管的远程git repo克隆数据（通过HTTP）时，我遇到了这个问题。 克隆本身也在AWS EC2实例上完成。

我尝试了上述所有解决方案及其组合：

  • 设置git的http.postBuffer
  • 设置http.maxrequestbuffer
  • 关闭git压缩并尝试“浅”git clone然后git fetch --unshallow - 请参阅fatal: early EOF fatal: index-pack failed
  • 调整GIT内存设置 - packedGitLimit 等，见这里：fatal: early EOF fatal: index-pack failed
  • 调整nginx配置 - 将client_max_body_size设置为大值和0（无限制）;设置proxy_request_buffering off;
  • 在/etc/resolv.conf
    • 中设置options single-request
  • 使用trickle
    • 限制git客户端吞吐量
  • 使用strace跟踪git clone
  • 考虑更新git客户端

在所有这些之后，我仍然一遍又一遍地面对同样的问题，直到我发现问题出在Elastic Load Balancer（ELB）切断连接。 在直接访问EC2实例（一个托管git repo）而不是通过ELB之后我终于设法克隆了git repo！ 我仍然不确定哪个ELB（超时）参数对此负责，所以我仍然需要做一些研究。

<强>更新

似乎通过将超时时间从20秒提高到300秒来更改AWS Elastic Load Balancer的连接耗尽策略，为我们解决了这个问题。

git clone错误与“连接耗尽”之间的关系很奇怪，对我们来说并不明显。可能是连接耗尽超时更改导致ELB配置中的一些内部更改修复了过早连接关闭的问题。

这是AWS论坛上的相关问题（尚未回答）：https://forums.aws.amazon.com/thread.jspa?threadID=258572

答案 12 :(得分：1)

我有类似的问题，但有一份竹子工作。 Bamboo无法在缓存存储库中执行本地克隆（本地但通过SSH代理），我删除了缓存，之后它工作正常，但只要它尝试从本地缓存克隆就会出现故障。看起来像竹子的SSH代理版本的问题本身就不是git。

答案 13 :(得分：1)

尝试这些解决方案花了几个小时，但最终归结为企业IPS（入侵防护系统）在传输了一定数量的数据后中断了连接。

答案 14 :(得分：1)

上面的技巧对我没有帮助，因为回购大于github上允许的最大推送大小。起作用的是https://github.com/git-lfs/git-lfs/issues/3758的建议，建议一次推动一点：

  

如果您的分支机构历史悠久，可以尝试将较小的分支   一次（例如2000年）的提交次数，如下所示：

git rev-list --reverse master | ruby -ne 'i ||= 0; i += 1; puts $_ if i % 2000 == 0' | xargs -I{} git push origin +{}:refs/heads/master
     

这将遍历母版的历史，一次推送2000个对象。 （当然，您可以在两个   如果愿意的话。）完成后，您应该可以推送   掌握最后一次，事情应该是最新的。如果也是2000   很多，您又遇到问题了，您可以调整数字，这样   较小。

答案 15 :(得分：1)

这解决了我的问题：

git clone --depth=20 https://repo.git -b master

答案 16 :(得分：1)

这是由于Internet连接问题，我遇到了同样的问题。 我使用

进行了浅层代码复制 
git clone --depth 1 //FORKLOCATION

后来使用克隆取消克隆

git fetch --unshallow

答案 17 :(得分：1)

使用BitBucket时遇到同样的错误。我所做的是从我的repo的URL中删除https并使用HTTP设置URL。 

git remote set-url origin http://mj@bitbucket.org/mj/pt.git

答案 18 :(得分：1)

好吧，我想推出一个219 MB的解决方案，但我没有运气

git config --global http.postBuffer 524288000

无论如何，拥有525 MB的帖子缓冲区有什么意义？这太傻了。所以我看了下面的git错误：

Total 993 (delta 230), reused 0 (delta 0)
POST git-receive-pack (5173245 bytes)
error: fatal: RPC failed; curl 56 SSL read: error:00000000:lib(0):func(0):reason(0), errno 10054

所以git想要发布5 MB，然后我将后置缓冲区设置为6 MB，并且可以正常工作

git config --global http.postBuffer 6291456

答案 19 :(得分：1)

我遇到了同样的问题而且它与一个糟糕的互联网连接有关，所以在尝试使用一些git配置后，我刚刚从我的网络断开连接并再次连接它就可以了！。

似乎连接丢失后（或触发此情况的动作），git卡住了。

我希望这可以为更多的人提供帮助。

最佳，

答案 20 :(得分：0)

通过ssh克隆存储库时，没有建议的解决方案对我有用。但是，我可以使用https进行克隆，然后通过以下方式将遥控器更改为ssh：

git remote set-url origin git@github.com:USERNAME/REPOSITORY.git

答案 21 :(得分：0)

对我来说，问题出在 MacOS 上安装的 Norton Security。一旦我暂时禁用了防火墙和其他诺顿防护，我的 git push 就可以正常工作。

答案 22 :(得分：0)

唯一对我有用的是：

  1. 克隆浅层：

    git clone <yourrepo> --depth 10

  2. 编辑 .git/config 如下：

之前

[remote "origin"]
    fetch = +refs/heads/master:refs/remotes/origin/master

之后

[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*

  1. git config --global http.maxRequestBuffer 100M git config --global core.compression 0

  2. Git 获取

答案 23 :(得分：0)

增加postBuffer的大小和maxRequestBuffer将帮助您解决此问题。只需按照步骤操作即可。

步骤：

1。打开终端或Git Bash，并用“ cd”转到您要克隆存储库的位置。

2。将压缩率设置为0 

git config --global core.compression 0

3。设置postBuffer大小

git config --global http.postBuffer 1048576000

4。设置maxRequestBuffer大小

git config --global http.maxRequestBuffer 100M

5。现在开始克隆

git clone <repo url>

6。等待克隆完成。

谢谢。祝您编码愉快！

答案 24 :(得分：0)

这对我有用，设置谷歌名称服务器，因为没有指定标准名称服务器，然后重新启动网络：

sudo echo "dns-nameservers 8.8.8.8" >> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0

答案 25 :(得分：0)

在MacOSX High Sierra上，对我而言，解决方案是：

brew install git-lfs

并且我的存储库已被克隆，没有任何错误。

答案 26 :(得分：0)

我必须删除git clone命令的分支标志。

答案 27 :(得分：0)

我正在从OS X El Capitan Mac进行git push。我得到了同样的错误，我尝试了一切修复，我在google / stackoverflow上发现了什么。就版本而言，我使用的是最新版本的github，即2.7.4。我在我的本地系统中创建了一个项目，我希望这个在我的github帐户中公开。项目规模不是8MB左右。我注意到，当我推送一些大小约为1.5MB的文件时，它正在推送正确，但是对于我而言，大尺寸失败，同样的错误，

我唯一的选择是推动MB块的变化。现在我推动了所有变化。这是我的解决方法，直到我得到修复此解决方案。

因此，您也可以尝试在多次提交中推送更改。或者，如果您有多个文件夹，则可以按每个文件夹推送更改（如果文件夹大小不大）。

希望这能帮助您继续开展项目。

答案 28 :(得分：0)

我遇到了同样的问题，正在网上寻找解决方案。我发现我们的IPv6企业路由没有得到维护。

我关闭了（Windows 10中以太网端口上的IPv6选项），没有问题。

答案 29 :(得分：0)

基于this answer，我尝试了以下操作（使用https网址）：

  1. 回购的初始克隆：

git clone --depth 25 url-here

  1. 获取提交的尝试深度每次增加两次：

git fetch --depth 50

git fetch --depth 100

git fetch --depth 200

...等等

  1. 最终（当我认为够了时）我运行git fetch --unshallow-完成了。

该过程显然需要更多时间，但就我而言，设置http.postBuffer和core.compression并没有帮助。

答案 30 :(得分：0)

使用ssh代替http，这不是一个很好的答案，但至少对我有用

答案 31 :(得分：0)

面对同样的问题，请尝试与另一个分支合并并从中吸取教训。 同样适用于我。

答案 32 :(得分：0)

我发现我的问题与.netrc文件一样，如果是这样，那么你也可以执行以下操作：

打开.netrc文件并对其进行编辑以包含github凭据。 输入nano ~/netrc或gedit ~/netrc

然后包括以下内容： *机器github.com

登录用户名

密码SECRET

machine api.github.com

登录用户名

密码SECRET *

您可以在那里添加原始密码，但出于安全考虑，请在github token生成身份验证令牌并将其粘贴代替您的密码。

希望这有助于某人

答案 33 :(得分：0)

使用WIFI路由器解决设置：

使用设置PPPoE（通过wifi路由器自动登录）进入wifi时，我遇到了同样的问题。

Git下载速度非常慢，只有15kb。

packet_write_wait：连接到17.121.133.16端口22：管道断开 致命：远端意外挂断 致命的：早期EOF 致命：索引包失败

解决方案： 1.将设置更改为动态IP，重新启动wifi路由器。 2.从Web浏览器登录到Internet服务提供商门户（不要配置PPPoE，从wifi路由器自动登录）。

更改Git后下载速度为1.7MiB。

答案 34 :(得分：0)

可能是因为提交的大小被推送。按以下步骤细分提交次数：

git log -5

查看最近5次提交，您将知道哪些未被推送到远程。 选择一个提交ID并将所有提交推送到该id：

git push <remote_name> <commit_id>:<branch_name>

注意：我刚检查了我的提交，它的大小可能最大;第一次推到那时。诀窍有效。!!

答案 35 :(得分：0)

它可能像服务器问题一样简单。如果使用GitHub，请检查https://twitter.com/githubstatus。我刚刚第一次看到这个并发现了GitHub's having a wobble。几分钟后，它再次运转良好。

答案 36 :(得分：-2)

检查您的网速。另请检查以下命令：

$ git config --global http.postBuffer 2M
$ git pull origin master
相关问题
最新问题