git clone 以 Broken Pipe 结尾

git clone ends with Broken Pipe

提问by Ethan Leroy

I have a very big git repository and want to clone from it. On one machine (ArchLinux with git version 2.2.2)everything works fine...

我有一个非常大的 git 存储库，想从中克隆。在一台机器上（ArchLinux with git version 2.2.2）一切正常......

Cloning into 'foo'
remote: Counting objects: 2372505, done
remote: Compressing objects: 100% (456914/456914), done.
Receiving objects: 100% (2372505/2372505), 3.81 GiB | 6.20 MiB/s, done.
...

... but on another machine (Ubuntu with git version 2.3.0, also tried with 1.7.0.4), I only see the following:

...但在另一台机器上（使用 git 版本 2.3.0 的 Ubuntu，也尝试使用 1.7.0.4），我只看到以下内容：

Cloning into 'foo'
remote: Counting objects: 2372505, done.

and after some hours, it ends with

几个小时后，它以

Write failed: Broken pipe
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Any idea what's the problem?

知道有什么问题吗？

By the way:

顺便一提：

• The remote end is a gitlab server.
• I'm using SSH in both cases.
• The first (working) machine is connected via VPN (100 MBit/s).
• The second (non-working) machine is in the same gigabit-subnet as the gitlab server.

• 远端是一个 gitlab 服务器。
• 我在这两种情况下都使用 SSH。
• 第一台（工作）机器通过 VPN (100 MBit/s) 连接。
• 第二台（非工作）机器与 gitlab 服务器在同一个千兆子网中。

采纳答案by Ethan Leroy

Solved!I used a DNS name for connecting to the gitlab server, and what I didn't know: This name has been resolved to the external IP of the same server, so, the server and the client were not in the same subnet.

解决了！我使用了一个DNS名称连接到gitlab服务器，而我不知道的是：该名称已解析为同一服务器的外部IP，因此，服务器和客户端不在同一子网中。

So, the client connected to the external IP of the server, so the firewall had to NAT it back to the server.

因此，客户端连接到服务器的外部 IP，因此防火墙必须将其 NAT 回服务器。

The solutionwas quite simple: I just added the hostname with the internal ip to the client machine's /etc/hostsfile and from that on the clone worked like a charm.

解决方案非常简单：我只是将带有内部 ip 的主机名添加到客户端机器的/etc/hosts文件中，然后克隆工作就像一个魅力。

回答by VonC

Regarding GitLab, this threadmentions (for a similar error)

关于 GitLab，这个线程提到（对于类似的错误）

I solved that issue (unable to checkout large repo' via HTTP) by editing git/config/unicorn.ymland setting timeout to 120, when it was previously 30, and restarting the gitab service.

我通过编辑git/config/unicorn.yml并将超时设置为 120（之前为 30）并重新启动 gitab 服务解决了该问题（无法通过 HTTP 签出大型 repo）。

If this is not only about the Git hosting server, but about Git itself, then you have other options to try:

如果这不仅与 Git 托管服务器有关，而且与 Git 本身有关，那么您还有其他选择可以尝试：

• The remote end hung up unexpectedly while git cloning
• fatal: early EOF fatal: index-pack failed

• git cloning 远程端意外挂断
• 致命：早期 EOF 致命：索引包失败

回答by PHZ.fi-Pharazon

For me, after trying out all suggestions found on the net, it turned out that the VPN connection was connecting and disconnecting constantly. It seems that if there is too many "network outages" or a lossy network, git clone "jams" and eventually you get the Broken pipe-error message.

对我来说，在尝试了网上找到的所有建议后，结果发现 VPN 连接一直在连接和断开连接。似乎如果有太多“网络中断”或有损网络， git clone “jams” 并最终您会收到 Broken pipe-error 消息。

To debug, if there is any real traffic going on, you can use

要调试，如果有任何真实的流量正在进行，您可以使用

iptraf

or

或者

tcpdump -ni eth0 host github.com

In my case, there was initially a steady flow of 2MB/s, but after a few secs, the underlying connection broke down, and the clone stream never recovered, until I fixed the OpenVPN connection to stay up more stable.

就我而言，最初有 2MB/s 的稳定流量，但几秒钟后，底层连接中断，克隆流从未恢复，直到我修复了 OpenVPN 连接以保持更稳定。