Odległy koniec rozłączył się nieoczekiwanie podczas klonowania gita

Mój gitklient wielokrotnie nie powiodło się z powodu następującego błędu po próbie klonowania repozytorium przez pewien czas.

Co może być tutaj problemem?

Uwaga: Zarejestrowałem swój klucz SSH u dostawcy hostingu GIT

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

Szybkie rozwiązanie:

Z tego rodzaju błędem zwykle zaczynam od zwiększenia postBufferrozmiaru o:

git config --global http.postBuffer 524288000

(niektóre komentarze poniżej wskazują na konieczność podwojenia wartości):

git config --global http.postBuffer 1048576000

Więcej informacji:

Od git configstrony człowieka , http.postBufferjest o:

Maksymalny rozmiar w bajtach bufora używanego przez inteligentny transport HTTP podczas wysyłania danych do zdalnego systemu.
W przypadku żądań większych niż ten rozmiar bufora Transfer-Encoding: chunkedużywany jest protokół HTTP / 1.1, aby uniknąć lokalnego tworzenia ogromnego pakietu. Domyślnie jest to 1 MiB, co wystarcza w przypadku większości żądań.

Nawet w przypadku klonu może to mieć wpływ, aw tym przypadku OP Joe informuje:

[klon] działa teraz dobrze

Uwaga: jeśli coś poszło nie tak po stronie serwera i jeśli serwer korzysta z Git 2.5+ (Q2 2015), komunikat o błędzie może być bardziej wyraźny.
Zobacz „ Klonowanie Git: zdalny koniec zawiesił się nieoczekiwanie, próbował zmienić, postBufferale nadal nie działa ”.

Kulai ( w komentarzach ) wskazuje na tę stronę Git rozwiązywania problemów Atlassian , która dodaje:

Error code 56wskazuje na zwijanie się, którego błąd CURLE_RECV_ERRORoznacza, że ​​wystąpił jakiś problem, który uniemożliwił otrzymanie danych podczas procesu klonowania.
Zazwyczaj jest to spowodowane ustawieniem sieciowym, zaporą ogniową, klientem VPN lub programem antywirusowym, który przerywa połączenie przed przesłaniem wszystkich danych.

Wspomina także o następującej zmiennej środowiskowej, aby pomóc w procesie debugowania.

# 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

Dzięki Git 2.25.1 (luty 2020) wiesz więcej o tym http.postBuffer„rozwiązaniu”.

Zobacz zatwierdzenie 7a2dc95 , zatwierdzenie 1b13e90 (22 stycznia 2020 r.) Autor: brian m. carlson ( bk2204) .
^{(Scalony przez Junio ​​C Hamano - gitster- w commit 53a8329 , 30 stycznia 2020)}
( Dyskusja na liście mailowej Git )

docs: wspomnij o zwiększeniu wartości http.postBuffer

^{Podpisano: brian m. Carlson}

Użytkownicy w wielu różnych sytuacjach mają problemy z wypychaniem HTTP.

Często problemy te wynikają z oprogramowania antywirusowego, filtrujących serwerów proxy lub innych sytuacji man-in-the-middle; innym razem są one spowodowane zwykłą zawodnością sieci.

Jednak powszechnym rozwiązaniem problemów z wypychaniem HTTP znalezionych w Internecie jest zwiększenie http.postBuffer.

Działa to w żadnej z wyżej wymienionych sytuacji i jest użyteczne tylko w niewielkiej, bardzo ograniczonej liczbie przypadków: w zasadzie, gdy połączenie nie obsługuje poprawnie protokołu HTTP / 1.1.

Dokumentuj, gdy podniesienie tej wartości jest właściwe i co faktycznie robi, i zniechęcaj ludzi do używania jej jako ogólnego rozwiązania problemów z wypychaniem, ponieważ tam nie jest ona skuteczna.

Dokumentacja na git config http.postBufferrazie obejmuje:

http.postBuffer

Maksymalny rozmiar w bajtach bufora używanego przez inteligentny transport HTTP podczas wysyłania danych do zdalnego systemu.
W przypadku żądań większych niż ten rozmiar bufora stosuje się HTTP / 1.1 i Transfer-Encoding: chunked, aby uniknąć lokalnego tworzenia ogromnego pliku paczki.
Domyślnie jest to 1 MiB, co wystarcza na większość żądań.

Należy zauważyć, że zwiększenie tego limitu jest skuteczne tylko w przypadku wyłączenia kodowania przesyłania fragmentarycznego i dlatego powinno się go stosować tylko wtedy, gdy zdalny serwer lub serwer proxy obsługuje tylko HTTP / 1.0 lub jest niezgodny ze standardem HTTP.
Podniesienie tego nie jest na ogół skutecznym rozwiązaniem dla większości problemów z wypychaniem, ale może znacznie zwiększyć zużycie pamięci, ponieważ cały bufor jest przydzielany nawet dla małych wypychań .

Ten sam błąd w przypadku Bitbucket. Naprawione przez

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

Sztuczka http.postBuffer nie działała dla mnie. Jednak:

Dla innych, którzy doświadczają tego problemu, może to być problem z GnuTLS. Jeśli ustawisz tryb Pełny, możesz zobaczyć, że podstawowy błąd wygląda mniej więcej tak, jak w poniższym kodzie.

Niestety, moim jedynym dotychczasowym rozwiązaniem jest użycie SSH.

Widziałem rozwiązanie opublikowane w innym miejscu, aby skompilować Git z OpenSSL zamiast GnuTLS. Jest aktywnym raport o błędzie do wydania tutaj .

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

Obs .: Zmiana http.postBuffermoże również wymagać skonfigurowania pliku konfiguracyjnego Nginx dla gitlab, aby akceptował większe rozmiary ciała dla klienta, poprzez dostrajanie wartości client_max_body_size.

Istnieje jednak obejście, jeśli masz dostęp do maszyny Gitlab lub maszyny w jej sieci, a to za pomocą git bundle.

1. przejdź do repozytorium git na maszynie źródłowej
2. biegać git bundle create my-repo.bundle --all
3. przenieś (np. za pomocą rsync) plik my-repo.bundle na komputer docelowy
4. na maszynie docelowej uruchom git clone my-repo.bundle
5. git remote set-url origin "path/to/your/repo.git"
6. git push

Wszystkiego najlepszego!

Jedyną rzeczą, która działała dla mnie, było sklonowanie repozytorium za pomocą łącza HTTPS zamiast łącza SSH .

Jeśli używasz protokołu https i pojawia się błąd.

Użyłem https zamiast http i to rozwiązało mój problem

git config --global https.postBuffer 524288000

Na podstawie tej odpowiedzi próbowałem (z adresem URL https):

1. wstępne klonowanie repo:

git clone --depth 25 url-here

2. pobieranie zatwierdza z rosnącym dwukrotnie na głębokość próby:

git fetch --depth 50

git fetch --depth 100

git fetch --depth 200

...i tak dalej

3. w końcu (kiedy myślę, że wystarczająca ilość jest pobierana) biegnę git fetch --unshallow- i gotowe.

Proces oczywiście zajmuje dużo więcej czasu, ale w moim przypadku ustawienia http.postBufferi core.compressionnie pomogło.

UPD : Dowiedziałem się, że pobieranie przez ssh działa na dowolny rozmiar repozytorium (wykryty przypadkowo), zrobione z git clone <ssh url>, pod warunkiem, że utworzyłeś klucze ssh. Po pobraniu repozytorium zmieniam adres zdalny za pomocągit remote set-url <https url to repo>

Mam rozwiązanie po użyciu poniższego polecenia:

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

Mam ten sam problem, naprawiłem to metodą prób i błędów. Zmieniłem wartość core.compression, aż zadziała.

Zacząłem od „git config --global core.compression 1” po 3 próbach

„git config --global core.compression 4” działało dla mnie.

Wynika to z problemu z połączeniem internetowym, napotkałem ten sam problem. Zrobiłem płytką kopię kodu za pomocą

git clone --depth 1 //FORKLOCATION

Później nie użyto klonu

git fetch --unshallow

w /etc/resolv.confdodać linię na końcu pliku

options single-request

Cóż, chciałem wypchnąć 219 MB rozwiązania, ale nie miałem szczęścia

git config --global http.postBuffer 524288000

A po co w ogóle mieć bufor pocztowy o wielkości 525 MB? to jest głupie. Więc spojrzałem na błąd git poniżej:

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

Więc git chce wysłać 5 MB, a potem utworzyłem bufor 6 MB i to działa

git config --global http.postBuffer 6291456

Miałem ten sam problem i był on związany ze złym połączeniem internetowym, więc po wypróbowaniu niektórych konfiguracji git właśnie odłączyłem się od mojej sieci i ponownie nawiązałem połączenie i działa!

Wygląda na to, że po utracie połączenia (lub akcji uruchamiającej tę sytuację) git utknął.

Mam nadzieję, że może to być pomoc dla kogoś więcej tutaj.

Najlepsza,

Miałem również ten sam problem. Przyczyną tego są opisy Kurtisa dotyczące GNUTLS.

Jeśli masz ten sam powód, a twój system to Ubuntu, możesz rozwiązać ten problem, instalując najnowszą wersję git z ppa:git-core/ppa. Polecenia są jak poniżej.

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

Napotkałem ten problem podczas klonowania danych (przez HTTP) ze zdalnego repozytorium git hostowanego na instancji AWS EC2 zarządzanej przez elastyczną łodygę fasoli. Samego klonowania dokonano również na instancji AWS EC2.

Wypróbowałem wszystkie wyżej wymienione rozwiązania i ich kombinacje:

• ustawienie git http.postBuffer
• oprawahttp.maxrequestbuffer
• wyłączenie kompresji git i próba „płytkiego”, git clonea następnie git fetch --unshallow- patrz fatal: early EOF fatal: index-pack nie powiodło się
• dostrajanie ustawień pamięci GIT - packedGitLimit i wsp., patrz tutaj: fatal: early EOF fatal: index-pack nie powiodło się
• strojenie konfiguracji nginx - ustawienie client_max_body_sizezarówno na dużą wartość, jak i na 0 (nieograniczona); oprawaproxy_request_buffering off;
• ustawienie options single-requestw /etc/resolv.conf
• dławienie przepustowości klienta git za pomocą strużki
• za pomocą strace do śledzenia git clone
• rozważanie aktualizacji klienta git

Po tym wszystkim ciągle napotykałem ten sam problem, dopóki nie odkryłem, że problem polega na tym, że Elastic Load Balancer (ELB) przerywa połączenie . Po uzyskaniu dostępu do instancji EC2 (tej, w której znajduje się repozytorium git repo) zamiast przejścia przez ELB, w końcu udało mi się sklonować repozytorium git! Nadal nie jestem pewien, który z parametrów ELB (limit czasu) jest za to odpowiedzialny, więc nadal muszę przeprowadzić badania.

AKTUALIZACJA

Wygląda na to, że zmiana zasad usuwania połączeń dla AWS Elastic Load Balancer poprzez zwiększenie limitu czasu z 20 do 300 sekund rozwiązała ten problem.

Związek między git clonebłędami a „wyczerpaniem połączenia” jest dla nas dziwny i nieoczywisty. Możliwe, że zmiana limitu czasu wyczerpania połączenia spowodowała pewne wewnętrzne zmiany w konfiguracji ELB, które naprawiły problem z przedwczesnym zamykaniem połączenia.

To jest powiązane pytanie na forum AWS (jeszcze nie ma odpowiedzi): https://forums.aws.amazon.com/thread.jspa?threadID=258572

Miałem podobny problem, ale z robotą bambusową. Bamboo nie wykonał lokalnego klonowania (lokalnego, ale przez proxy SSH) repozytorium w pamięci podręcznej, usunąłem pamięć podręczną i po tym zadziałało, ale za każdym razem, gdy próbuje sklonować z lokalnej pamięci podręcznej, występuje błąd. Wygląda na to, że problem z bambusową wersją serwera proxy SSH nie jest git per se.

Mam ten sam błąd podczas korzystania z BitBucket. To, co zrobiłem, to usunięcie https z adresu URL mojej repozytorium i ustawienie adresu URL za pomocą HTTP.

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

ROZWIĄZANE Z WIFI Ustawienia routera:

Mam ten sam problem, gdy jestem w Wi-Fi z ustawieniami PPPoE (automatyczne logowanie przez router Wi-Fi).

Szybkość pobierania Git jest bardzo wolna 15kb.

packet_write_wait: Połączenie z portem 17.121.133.16: Zgubiona rura śmiertelna: Zdalny koniec rozłączył się niespodziewanie śmiertelnie: wczesny błąd EOF: błąd pakietu indeksu

Rozwiązanie: 1. Zmieniono ustawienie na Dynamic IP, zrestartuj router Wi-Fi. 2. Z logowania przeglądarki internetowej do portalu dostawcy usług internetowych (nie konfiguruj PPPoE, automatyczne logowanie z routera Wi-Fi).

Po zmianie prędkość pobierania Gita wynosi 1,7 Mb.

To rozwiązało mój problem:

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

Powyższe wskazówki mi nie pomogły, ponieważ repo było większe niż maksymalny rozmiar push dozwolony w github. To, co zadziałało, było zaleceniem z https://github.com/git-lfs/git-lfs/issues/3758, które sugerowało, że należy popchnąć trochę:

Jeśli twoja gałąź ma długą historię, możesz spróbować wypchnąć mniejszą liczbę zatwierdzeń na raz (powiedzmy 2000) za pomocą czegoś takiego:

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

To przejdzie przez historię mistrza, pchając obiekty 2000 na raz. (Jeśli chcesz, możesz oczywiście zastąpić inną gałąź w obu miejscach.) Po zakończeniu tej czynności powinieneś być w stanie przeforsować mistrz po raz ostatni, a wszystko powinno być aktualne. Jeśli 2000 to za dużo i problem znów się pojawi, możesz dostosować liczbę, aby była mniejsza.

Zmarnowałem kilka godzin na wypróbowanie niektórych z tych rozwiązań, ale ostatecznie prześledziłem to w korporacyjnym systemie IPS (Instrusion Protection System), który porzucił połączenie po przesłaniu pewnej ilości danych.

W przypadku wspólnej przepustowości spróbuj sklonować, gdy obciążenie jest mniejsze. W przeciwnym razie spróbuj użyć połączenia o dużej prędkości. Jeśli nadal nie działa, użyj poniższego polecenia,

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

I spróbuj sklonować ponownie. Może być konieczna zmiana tych ustawień w zależności od dostępnego rozmiaru pamięci.

Może to być tak proste, jak problem z serwerem. Jeśli używasz GitHub, sprawdź https://twitter.com/githubstatus . Właśnie to zobaczyłem po raz pierwszy i odkryłem, że GitHub ma chwiejność . Kilka minut później znów zadziałało dobrze.

Działa to dla mnie, konfigurowanie serwera nazw Googles, ponieważ nie określono standardowego serwera nazw, a następnie restartowanie sieci:

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

Napotkałem ten problem za pomocą git w Kubuntu. Zauważyłem również ogólną niestabilność w sieci i znalazłem rozwiązanie .

w /etc/resolv.conf dodaj linię na końcu pliku

opcje pojedynczego żądania

To naprawiło opóźnienia, zanim każde rozpoznanie nazwy domeny i git zaczęło działać jak urok.

Odkryłem, że mój problem dotyczy pliku .netrc. Jeśli tak, również dla Ciebie, możesz wykonać następujące czynności:

Otwórz plik .netrc i edytuj go, aby zawierał poświadczenia github. Wpisz nano ~/netrclubgedit ~/netrc

Następnie dołącz następujące informacje: * machine github.com

Login nazwa użytkownika

hasło TAJNE

maszyna api.github.com

Login nazwa użytkownika

hasło SECRET *

Możesz podać tam swoje surowe hasło, ale ze względów bezpieczeństwa wygeneruj tutaj token uwierzytelniania github i wklej go zamiast hasła.

Mam nadzieję, że to komuś pomoże

Może to być spowodowane przepychaniem wielkości zatwierdzeń. Podział liczby zatwierdzeń według następujących kroków:

git log -5

Zobacz 5 ostatnich zatwierdzeń, a będziesz wiedział, które nie są wypychane na odległość. Wybierz identyfikator zatwierdzenia i wypchnij wszystkie zatwierdzenia do tego identyfikatora:

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

UWAGA: Właśnie sprawdziłem swoje zatwierdzenie, które może mieć największy rozmiar; najpierw podnoszony do tego czasu. Trik zadziałał !!

Robiłem git push z mojego Mac OS X El Capitan. Otrzymywałem ten sam błąd, próbowałem wszystko naprawić, co znalazłem w google / stackoverflow. Jeśli chodzi o wersję, używam dość najnowszej wersji github, czyli 2.7.4. W moim systemie lokalnym stworzyłem projekt i chciałem, aby był on publiczny na moim koncie github. Rozmiar projektu nie wynosił około 8 MB. Zauważyłem, że kiedy przepychałem niektóre pliki o rozmiarze około 1,5 MB, przesuwało się ono poprawnie, ale przy dużym rozmiarze nie powiodło się dla mnie, z tym samym błędem,

Jedyną opcją, jaką miałem, było wypychanie zmian w części MB. Teraz wprowadziłem wszystkie zmiany. Jest to dla mnie obejście, dopóki nie naprawię tego rozwiązania.

Możesz więc także spróbować wprowadzić zmiany w wielokrotnym zatwierdzeniu. Lub jeśli masz wiele folderów, możesz wypychać zmiany według każdego folderu (jeśli rozmiar folderu nie jest duży).

Mam nadzieję, że to pomoże ci w ciągłej pracy nad projektem.

W obliczu tego samego problemu spróbuj połączyć się z inną gałęzią i pociągnij ich. To działa dla mnie tak samo.

użyj sshzamiast http, to nie jest dobra odpowiedź na to pytanie, ale przynajmniej działa dla mnie