The remote end hung up unexpectedly while git cloning
GitGit Problem Overview
My git
client repeatedly fails with the following error after trying to clone the repository for some time.
What could be the issue here?
Note: I have registered my SSH key with the GIT hosting provider
Receiving objects: 13% (1309/10065), 796.00 KiB | 6 KiB/s
fatal: The remote end hung up unexpectedly
Git Solutions
Solution 1 - Git
Quick solution:
With this kind of error, I usually start by raising the postBuffer
size by:
git config --global http.postBuffer 524288000
(some comments below report having to double the value):
git config --global http.postBuffer 1048576000
(For npm publish
, Martin Braun reports in the comments setting it to no more than 50 000 000 instead of the default 1 000 000)
###More information:
From the git config
man page, http.postBuffer
is about:
> Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system.
For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked
is used to avoid creating a massive pack file locally. Default is 1 MiB, which is sufficient for most requests.
Even for the clone, that can have an effect, and in this instance, the OP Joe reports:
> [clone] works fine now
Note: if something went wrong on the server side, and if the server uses Git 2.5+ (Q2 2015), the error message might be more explicit.
See "Git cloning: remote end hung up unexpectedly, tried changing postBuffer
but still failing".
Kulai (in the comments) points out to this Atlassian Troubleshooting Git page, which adds:
> Error code 56
indicates a curl receive the error of CURLE_RECV_ERROR
which means there was some issue that prevented the data from being received during the cloning process.
Typically this is caused by a network setting, firewall, VPN client, or anti-virus that is terminating the connection before all data has been transferred.
It also mentions the following environment variable, order to help with the debugging process.
# 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
With Git 2.25.1 (Feb. 2020), you know more about this http.postBuffer
"solution".
See commit 7a2dc95, commit 1b13e90 (22 Jan 2020) by brian m. carlson (bk2204
).
(Merged by Junio C Hamano -- gitster
-- in commit 53a8329, 30 Jan 2020)
(Git Mailing list discussion)
> ## docs
: mention when increasing http.postBuffer is valuable
> Signed-off-by: brian m. carlson
> Users in a wide variety of situations find themselves with HTTP push problems.
>
> Oftentimes these issues are due to antivirus software, filtering proxies, or other man-in-the-middle situations; other times, they are due to simple unreliability of the network.
>
> However, a common solution to HTTP push problems found online is to increase http.postBuffer.
>
> This works for none of the aforementioned situations and is only useful in a small, highly restricted number of cases: essentially, when the connection does not properly support HTTP/1.1.
>
> Document when raising this value is appropriate and what it actually does, and discourage people from using it as a general solution for push problems, since it is not effective there.
So the documentation for git config http.postBuffer
now includes:
> ## http.postBuffer
> Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system.
For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked is used to avoid creating a massive pack file locally.
Default is 1 MiB, which issufficient for most requests.
>
> Note that raising this limit is only effective for disabling chunked transfer encoding and therefore should be used only where the remote server or a proxy only supports HTTP/1.0 or is noncompliant with the HTTP standard.
Raising this is not, in general, an effective solution for most push problems, but can increase memory consumption significantly since the entire buffer is allocated even for small pushes.
Solution 2 - Git
Same error with Bitbucket. Fixed by
git config --global http.postBuffer 500M
git config --global http.maxRequestBuffer 100M
git config --global core.compression 0
Solution 3 - Git
The http.postBuffer trick did not work for me. However:
For others experiencing this problem, it may be an issue with GnuTLS. If you set Verbose mode, you may see the underlying error look something along the lines of the code below.
Unfortunately, my only solution so far is to use SSH.
I've seen a solution posted elsewhere to compile Git with OpenSSL instead of GnuTLS. There is an active bug report for the issue 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
Solution 4 - Git
Based on this answer, I tried following (with https url):
- initial cloning of repo:
git clone --depth 25 url-here
- fetch commits with increasing twice per try depth:
git fetch --depth 50
git fetch --depth 100
git fetch --depth 200
...and so on
- eventually (when I think enough is fetched) I run
git fetch --unshallow
- and it's done.
The process obviously takes much more time, but in my case setting http.postBuffer
and core.compression
didn't help.
UPD: I found out that fetching via ssh works for any repo size (discovered accidentally), done with git clone <ssh url>
, given you have created ssh keys. Once repo is fetched, I change remote address using git remote set-url <https url to repo>
Solution 5 - Git
The only thing that worked for me was to clone the repo using the HTTPS link instead of the SSH link.
Solution 6 - Git
This is due the internet connectivity issue, i faced the same issue. I did a shallow copy of code using
git clone --depth 1 //FORKLOCATION
Later unshallowed the clone using
git fetch --unshallow
Solution 7 - Git
For shared bandwidth try to clone when load is less. Otherwise, try with a high speed connection. If still does not work, please use below command,
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
And try to clone again. You might need to change those settings according to your available memory size.
Solution 8 - Git
Obs.: Changing http.postBuffer
might also require to set up the Nginx configuration file for gitlab to accept larger body sizes for the client, by tuning the value of client_max_body_size.
However, there is a workaround if you have access to the Gitlab machine or to a machine in its network, and that is by making use of git bundle
.
- go to your git repository on the source machine
- run
git bundle create my-repo.bundle --all
- transfer (eg., with rsync) the my-repo.bundle file to the destination machine
- on the destination machine, run
git clone my-repo.bundle
git remote set-url origin "path/to/your/repo.git"
git push
All the best!
Solution 9 - Git
If you are using https and you are getting the error.
I used https instead of http and it solved my problem
git config --global https.postBuffer 524288000
Solution 10 - Git
I got solution after using below command:
git repack -a -f -d --window=250 --depth=250
Solution 11 - Git
I got the same issue, I fixed this with trial and error method. I changed the core.compression value until it works.
I started with "git config --global core.compression 1" after 3 attempts
"git config --global core.compression 4" worked for me.
Solution 12 - Git
Well, I wanted to push a 219 MB solution, but I had no luck with
git config --global http.postBuffer 524288000
And what's the point of having a 525 MB post buffer anyway? it's silly. So I looked at the git error below:
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
So git want's to post 5 MB, then I made the post buffer 6 MB, and it works
git config --global http.postBuffer 6291456
Solution 13 - Git
I was facing this issue when cloning data (via HTTP) from remote git repo hosted on AWS EC2 instance managed by elastic beanstalk. The cloning itself was also done on AWS EC2 instance.
I tried all aforementioned solutions and their combinations:
- setting git's
http.postBuffer
- setting
http.maxrequestbuffer
- turning off git compression and trying "shallow"
git clone
and thengit fetch --unshallow
- see https://stackoverflow.com/questions/21277806/fatal-early-eof-fatal-index-pack-failed/22317479#22317479 - tunning GIT memory settings -
packedGitLimit
et al, see here: https://stackoverflow.com/questions/21277806/fatal-early-eof-fatal-index-pack-failed/29355320#29355320 - tunning nginx configuration - setting
client_max_body_size
to both big value and 0 (unlimited); settingproxy_request_buffering off;
- setting
options single-request
in /etc/resolv.conf - throttling git client throughput with trickle
- using strace for tracing
git clone
- considering update of git client
After all of this, I was still facing the same issue over and over again, until I found that issue is in Elastic Load Balancer (ELB) cutting the connection. After accessing the EC2 instance (the one hosting git repo) directly instead of going through ELB I've finally managed to clone git repo! I'm still not sure which of ELB (timeout) parameters is responsible for this, so I still have to do some research.
UPDATE
It seems that changing Connection Draining policy for AWS Elastic Load Balancer by raising timeout from 20 seconds to 300 seconds resolved this issue for us.
The relation between the git clone
errors and "connection draining" is strange and not obvious to us. It might be that connection draining timeout change caused some internal changes in ELB configuration that fixed the issue with premature connection closing.
This is the related question on AWS forum (no answer yet): https://forums.aws.amazon.com/thread.jspa?threadID=258572
Solution 14 - Git
in /etc/resolv.conf
add the line to the end of the file
options single-request
Solution 15 - Git
I also had the same problem.The reason for this problem is as Kurtis's descriptions about GNUTLS.
If you have the same reason and your system is Ubuntu, you can solve this problem by installing the latest version of git from ppa:git-core/ppa
.The commands are as below.
sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get git
Solution 16 - Git
I had the same issue and it was related with a bad internet connection, so after try with some git configs, i've just disconnected from my network and connected again and it works!.
It seems that after connection lost (or the action that fires this situation), git is stuck.
I hope that it could be a help for someone more here.
Best,
Solution 17 - Git
Wasted a few hours trying some of these solutions but eventually traced this to a corporate IPS (Instrusion Protection System) dropping the connection after a certain amount of data is transferred.
Solution 18 - Git
I had a similar problem, but with a bamboo job. Bamboo was failing doing a local clone (local but over an SSH proxy) of a cached repository, I deleted the cache and after that it worked, but any time it tries to clone from the local cache there is a failure. Seems like a problem with bamboo's version of the SSH proxy not git per se.
Solution 19 - Git
I faced with this problem using git in Kubuntu. I've also noticed overall instability in networking and found a solution. >in /etc/resolv.conf >add the line to the end of the file > >options single-request
This fixed delays before every domain name resolution and git started to work like a charm after this.
Solution 20 - Git
SOLVED WITH WIFI Router Setting :
I got same issue when I am in wifi with Settings PPPoE(auto login by wifi router).
Git download speed is very slow 15kb.
packet_write_wait: Connection to 17.121.133.16 port 22: Broken pipe fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed
Solution :
- Changed setting to Dynamic IP, reboot wifi router.
- From web browser login to Internet service provider portal (do not configure PPPoE , auto login from the wifi router).
After changing Git download speed is 1.7MiB.
Solution 21 - Git
use ssh
instead of http
, it's not a good answer for this question but at least it works for me
Solution 22 - Git
This solved my problem:
git clone --depth=20 https://repo.git -b master
Solution 23 - Git
The tricks above did not help me, as the repo was larger than the max push size allowed at github. What did work was a recommendation from https://github.com/git-lfs/git-lfs/issues/3758 which suggested pushing a bit at a time:
> If your branch has a long history, you can try pushing a smaller > number of commits at a time (say, 2000) with something like this: > > git rev-list --reverse master | ruby -ne 'i ||= 0; i += 1; puts $_ if i % 2000 == 0' | xargs -I{} git push origin +{}:refs/heads/master > > That will walk through the history of master, pushing objects 2000 at a time. (You can, of course, substitute a different branch in both > places if you like.) When that's done, you should be able to push > master one final time, and things should be up to date. If 2000 is too > many and you hit the problem again, you can adjust the number so it's > smaller.
Solution 24 - Git
I had to remove the branch flag for the git clone
command.
Solution 25 - Git
On MacOSX High Sierra the solution for me was:
brew install git-lfs
and my repository was cloned without any errors.
Solution 26 - Git
Increasing postBuffer size and maxRequestBuffer will help you in this problem. Just follow the steps.
steps:
1 .Open terminal or Git Bash and with "cd" go to the location where you wanted to clone repo.
2.Set compression to 0
git config --global core.compression 0
3.Set postBuffer size
git config --global http.postBuffer 1048576000
4.Set maxRequestBuffer size
git config --global http.maxRequestBuffer 100M
5.Now start clone
git clone <repo url>
6.Wait till clone get complete.
Thank you. Happy Coding !!!
Solution 27 - Git
It may be as simple as a server problem. If using GitHub, check https://twitter.com/githubstatus. I saw this for the first time just now and discovered GitHub's having a wobble. A few minutes later it worked again fine.
Solution 28 - Git
This worked for me, setting up Googles nameserver because no standard nameserver was specified, followed by restarting networking:
sudo echo "dns-nameservers 8.8.8.8" >> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0
Solution 29 - Git
I was doing git push from my OS X El Capitan Mac. I was getting same error, I tried everything to fix, what I found on google/stackoverflow. As far as version is concerned I am using fairly latest version of github which is 2.7.4. I have create a project in my local system, and I wanted this to be public in my github account. Project size was not around 8MB. I noticed that when I was pushing some files of size around 1.5MB, it was pushing properly, but with large size failed for me, with same error,
Only option I had was to push changes in chunk of MB. Now I have pushed all changes. This is workaround for me until I get fix for this solution.
So you can also try pushing change in multiple commit. Or if you have multiple folder you can push changes by each folder (if folder size is not big).
Hope this will help you to continuous working on project.
Solution 30 - Git
I found my problem to be with the .netrc file, if so for you too then you can do the following:
Open your .netrc file and edit it to include github credentials.
Type nano ~/netrc
or gedit ~/netrc
Then include the following: *machine github.com
login username
password SECRET
machine api.github.com
login username
password SECRET*
You can include your raw password there but for security purposes, generate an auth token here github token and paste it in place of your password.
Hope this helps someone
Solution 31 - Git
I have the same error while using BitBucket. What I did was remove https from the URL of my repo and set the URL using HTTP
.
git remote set-url origin http://[email protected]/mj/pt.git
Solution 32 - Git
It might be because of commits' size that are being pushed.. Breakdown the number of commits by the following steps:
git log -5
See the last 5 commits and you would know which ones are not pushed to remote. Select a commit id and push all commits up to that id:
git push <remote_name> <commit_id>:<branch_name>
NOTE: I just checked my commit which could have the biggest size; first pushed up till then. The trick worked.!!
Solution 33 - Git
Faced same issue, try to merge with another branch and take a pull from them. It works for me same.
Solution 34 - Git
I had the same issue and was searching the solution around web. I found that our corporate routing in IPv6 is not maintained.
I turn off the (IPv6 option on the ethernet port in Windows 10) and there is no issue.
Solution 35 - Git
None of the suggested solutions worked for me when cloning a repository via ssh
. However, I was able to clone using https
, then later changed the remote to ssh
via:
git remote set-url origin git@github.com:USERNAME/REPOSITORY.git
Solution 36 - Git
The only thing that worked for me was this:
-
Clone shallow:
git clone <yourrepo> --depth 10
-
Edited .git/config as follows:
Before
[remote "origin"]
fetch = +refs/heads/master:refs/remotes/origin/master
After
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
3.
git config --global http.maxRequestBuffer 100M
git config --global core.compression 0
4. Git fetch
Solution 37 - Git
For me the problem was with Norton Security installed on MacOS. Once I've temporary disabled firewall and other Norton protections, my git push
worked correctly.
Solution 38 - Git
changing depth to 25 in source tree advanced options in the clone screen worked for me
Solution 39 - Git
Running the git push...
from Mac
terminal made the trick, which was different than trying from an IDE
(my case: VSCode
) which caused the issue.
Solution 40 - Git
My experience was that this was definitely a connectivity timeout somewhere.
Eventually solved by plugging in a crappy little wifi dongle to my PC, and using my phone's hotspot.
When I was on a wired connection to my ISP, it was fine uploading a small change to Github, so connectivity and authentication worked in principle. But when trying to push a new 80Mb repository, the error occurred.
After managing to push the repo over the wifi dongle / hotspot, small incremental changes went up fine.
Solution 41 - Git
Check your internet speed. Also check the following commands:
$ git config --global http.postBuffer 2M
$ git pull origin master