L'estremità remota si è bloccata inaspettatamente durante la clonazione di git

Il mio gitclient fallisce ripetutamente con il seguente errore dopo aver provato a clonare il repository per qualche tempo.

Quale potrebbe essere il problema qui?

Nota: ho registrato la mia chiave SSH con il provider di hosting GIT

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

Soluzione rapida:

Con questo tipo di errore, di solito inizio sollevando il postBuffer dimensione di:

git config --global http.postBuffer 524288000

(alcuni commenti qui sotto riportano la necessità di raddoppiare il valore):

git config --global http.postBuffer 1048576000

Maggiori informazioni:

Dalla git configpagina man ,http.postBuffer parla di:

Dimensione massima in byte del buffer utilizzata dai trasporti HTTP intelligenti durante il POST di dati sul sistema remoto.
Per richieste superiori a questa dimensione del buffer, HTTP / 1.1 eTransfer-Encoding: chunked viene utilizzato per evitare di creare localmente un file pack di grandi dimensioni. L'impostazione predefinita è 1 MiB, che è sufficiente per la maggior parte delle richieste.

Anche per il clone, ciò può avere un effetto, e in questo caso, OP Joe riporta:

[clone] ora funziona bene

Nota: se qualcosa è andato storto sul lato server e se il server utilizza Git 2.5+ (Q2 2015), il messaggio di errore potrebbe essere più esplicito.
Vedi " Clonazione Git: l'estremità remota ha riattaccato inaspettatamente, ha provato a cambiare postBufferma continua a fallire ".

Kulai ( nei commenti ) sottolinea questa pagina Git di risoluzione dei problemi di Atlassian , che aggiunge:

Error code 56indica che un ricciolo riceve l'errore, il CURLE_RECV_ERRORche significa che c'era qualche problema che impediva la ricezione dei dati durante il processo di clonazione.
In genere, ciò è causato da un'impostazione di rete, firewall, client VPN o antivirus che interrompe la connessione prima che tutti i dati siano stati trasferiti.

Menziona anche la seguente variabile d'ambiente, per aiutare con il processo di debug.

# 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

Con Git 2.25.1 (febbraio 2020), ne sai di più http.postBuffer "soluzione".

Vedi commit 7a2dc95 , commit 1b13e90 (22 gennaio 2020) di brian m. Carlson ( bk2204) .
^{(Unito da Junio ​​C Hamano - gitster- in commit 53a8329 , 30 gennaio 2020)}
( Discussione su Git Mailing list )

docs: menzionare quando aumentare http.postBuffer è prezioso

^{Firmato-fuori-da: brian m. Carlson}

Gli utenti in un'ampia varietà di situazioni si trovano con problemi di push HTTP.

Spesso questi problemi sono dovuti a software antivirus, proxy di filtro o altre situazioni man-in-the-middle; altre volte, sono dovuti alla semplice inaffidabilità della rete.

Tuttavia, una soluzione comune ai problemi di push HTTP rilevati online è quella di aumentare http.postBuffer.

Questo non funziona per nessuna delle situazioni di cui sopra ed è utile solo in un numero limitato di casi: in sostanza, quando la connessione non supporta correttamente HTTP / 1.1.

Documentare quando aumentare questo valore è appropriato e ciò che effettivamente fa e scoraggiare le persone dall'usarlo come soluzione generale per problemi di spinta, dal momento che non è efficace lì.

Quindi la documentazione per git config http.postBufferora include:

http.postBuffer

Dimensione massima in byte del buffer utilizzata dai trasporti HTTP intelligenti durante il POST di dati sul sistema remoto.
Per richieste di dimensioni superiori a questa dimensione del buffer, HTTP / 1.1 e Transfer-Encoding: chunked viene utilizzato per evitare la creazione di un file pack imponente localmente.
L'impostazione predefinita è 1 MiB, che è sufficiente per la maggior parte delle richieste.

Si noti che l'innalzamento di questo limite è efficace solo per disabilitare la codifica di trasferimento in blocchi e pertanto deve essere utilizzato solo dove il server remoto o un proxy supporta solo HTTP / 1.0 o non è conforme allo standard HTTP.
Sollevare questo non è, in generale, una soluzione efficace per la maggior parte dei problemi di push, ma può aumentare significativamente il consumo di memoria poiché l'intero buffer è allocato anche per piccoli push .

Stesso errore con Bitbucket. Risolto da

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

Il trucco http.postBuffer non ha funzionato per me. Però:

Per gli altri che riscontrano questo problema, potrebbe trattarsi di un problema con GnuTLS. Se imposti la modalità dettagliata, potresti vedere l'errore sottostante apparire simile alle righe del codice qui sotto.

Sfortunatamente, la mia unica soluzione finora è usare SSH.

Ho visto una soluzione pubblicata altrove per compilare Git con OpenSSL invece di GnuTLS. C'è una segnalazione di bug attiva per il problema qui .

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

Nota: la modifica http.postBufferpotrebbe richiedere anche l'impostazione del file di configurazione Nginx affinché gitlab accetti le dimensioni corporee maggiori per il client, ottimizzando il valore di client_max_body_size.

Tuttavia, esiste una soluzione alternativa se si ha accesso alla macchina Gitlab o a una macchina nella sua rete, e questo è facendo uso di git bundle.

1. vai al tuo repository git sul computer di origine
2. correre git bundle create my-repo.bundle --all
3. trasferire (ad es. con rsync) il file my-repo.bundle sulla macchina di destinazione
4. sulla macchina di destinazione, eseguire git clone my-repo.bundle
5. git remote set-url origin "path/to/your/repo.git"
6. git push

Ti auguro il meglio!

L'unica cosa che ha funzionato per me è stata la clonazione del repository utilizzando il collegamento HTTPS anziché il collegamento SSH .

Se stai usando https e stai ricevendo l'errore.

Ho usato https invece di http e ha risolto il mio problema

git config --global https.postBuffer 524288000

Sulla base di questa risposta , ho provato a seguire (con https url):

1. clonazione iniziale di pronti contro termine:

git clone --depth 25 url-here

2. recupera si impegna aumentando due volte per profondità di prova:

git fetch --depth 50

git fetch --depth 100

git fetch --depth 200

...e così via

3. alla fine (quando penso che sia abbastanza recuperato) corro git fetch --unshallow- e il gioco è fatto.

Il processo ovviamente richiede molto più tempo, ma nel mio caso l'impostazione http.postBuffere core.compressionnon ha aiutato.

UPD : Ho scoperto che il recupero tramite ssh funziona per qualsiasi dimensione di repository (scoperto per caso), fatto git clone <ssh url>, dato che hai creato i tasti ssh. Una volta recuperato il repository, cambio l'indirizzo remoto utilizzandogit remote set-url <https url to repo>

Ho ottenuto una soluzione dopo aver usato il comando seguente:

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

Ho avuto lo stesso problema, l'ho risolto con il metodo di prova ed errore. Ho modificato il valore core.compression fino a quando non funziona.

Ho iniziato con "git config --global core.compression 1" dopo 3 tentativi

"git config --global core.compression 4" ha funzionato per me.

Ciò è dovuto al problema della connettività Internet, ho riscontrato lo stesso problema. Ho fatto una copia superficiale del codice usando

git clone --depth 1 //FORKLOCATION

In seguito, il clone non è stato svelato usando

git fetch --unshallow

in /etc/resolv.confaggiungi la riga alla fine del file

options single-request

Bene, volevo spingere una soluzione da 219 MB, ma non ho avuto fortuna

git config --global http.postBuffer 524288000

E a che serve avere un post buffer da 525 MB? è sciocco. Quindi ho visto l'errore git di seguito:

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

Quindi git vuole pubblicare 5 MB, poi ho creato il buffer post 6 MB, e funziona

git config --global http.postBuffer 6291456

Ho avuto lo stesso problema ed era correlato a una cattiva connessione a Internet, quindi dopo aver provato con alcune configurazioni git, mi sono appena disconnesso dalla mia rete e ricollegato e funziona !.

Sembra che dopo aver perso la connessione (o l'azione che genera questa situazione), git è bloccato.

Spero che possa essere di aiuto per qualcuno di più qui.

Migliore,

Ho anche avuto lo stesso problema. La ragione di questo problema è dovuta alle descrizioni di Kurtis su GNUTLS.

Se hai lo stesso motivo e il tuo sistema è Ubuntu, puoi risolvere questo problema installando l'ultima versione di git da ppa:git-core/ppa. I comandi sono i seguenti.

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

Stavo affrontando questo problema durante la clonazione dei dati (tramite HTTP) dal repository git remoto ospitato sull'istanza AWS EC2 gestita da beanstalk elastico. La clonazione stessa è stata eseguita anche su istanza AWS EC2.

Ho provato tutte le soluzioni di cui sopra e le loro combinazioni:

• impostazione di git http.postBuffer
• ambientazionehttp.maxrequestbuffer
• disattivando la compressione git e provando "shallow" git clonee quindi git fetch --unshallow- vedi fatale: inizio EOF fatale: pacchetto di indici fallito
• sintonizzazione delle impostazioni della memoria GIT - packedGitLimit et al, vedi qui: fatale: inizio EOF fatale: pacchetto di indici fallito
• sintonizzazione della configurazione di nginx - impostazione client_max_body_size su big value e 0 (illimitato); ambientazioneproxy_request_buffering off;
• ambientazione options single-request in /etc/resolv.conf
• limitare la velocità del client git con il gocciolamento
• usando strace per tracciare git clone
• considerando l'aggiornamento del client git

Dopo tutto questo, stavo ancora affrontando lo stesso problema ancora e ancora, fino a quando ho scoperto che il problema è in Elastic Load Balancer (ELB) che taglia la connessione . Dopo aver effettuato l'accesso all'istanza EC2 (quella che ospita git repo) direttamente invece di passare attraverso ELB sono finalmente riuscito a clonare git repo! Non sono ancora sicuro di quale dei parametri ELB (timeout) sia responsabile di questo, quindi devo ancora fare qualche ricerca.

AGGIORNARE

Sembra che cambiando la politica di svuotamento della connessione per AWS Elastic Load Balancer aumentando il timeout da 20 secondi a 300 secondi abbia risolto questo problema per noi.

La relazione tra git cloneerrori e "svuotamento della connessione" è strana e per noi non ovvia. È possibile che la modifica del timeout di svuotamento della connessione abbia causato alcune modifiche interne alla configurazione ELB che hanno risolto il problema con la chiusura prematura della connessione.

Questa è la domanda correlata sul forum AWS (ancora nessuna risposta): https://forums.aws.amazon.com/thread.jspa?threadID=258572

Ho avuto un problema simile, ma con un lavoro di bambù. Bamboo non stava eseguendo un clone locale (locale ma su un proxy SSH) di un repository memorizzato nella cache, ho eliminato la cache e successivamente ha funzionato, ma ogni volta che tenta di clonare dalla cache locale si verifica un errore. Sembra un problema con la versione di bambù del proxy SSH non git di per sé.

Ho lo stesso errore durante l'utilizzo di BitBucket. Quello che ho fatto è stato rimuovere https dall'URL del mio repository e impostare l'URL utilizzando HTTP.

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

RISOLTO CON Impostazione del router WIFI:

Ho avuto lo stesso problema quando sono in wifi con Impostazioni PPPoE (accesso automatico tramite router wifi).

La velocità di download di Git è molto lenta 15kb.

packet_write_wait: connessione alla porta 17.121.133.16 22: tubo interrotto fatale: l'estremità remota riattaccò inaspettatamente fatale: inizio EOF fatale: index-pack fallito

Soluzione: 1. Modificata l'impostazione su IP dinamico, riavviare il router wifi. 2. Dal login del browser Web al portale del provider di servizi Internet (non configurare PPPoE, accesso automatico dal router wifi).

Dopo aver modificato la velocità di download di Git è di 1,7 MiB.

Questo ha risolto il mio problema:

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

I trucchi di cui sopra non mi hanno aiutato, poiché il repository era più grande della dimensione di spinta massima consentita su Github. Ciò che ha funzionato è stata una raccomandazione di https://github.com/git-lfs/git-lfs/issues/3758 che ha suggerito di spingere un po 'alla volta:

Se la tua filiale ha una lunga storia, puoi provare a inviare un numero minore di commit alla volta (diciamo, 2000) con qualcosa del genere:

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

Camminerà attraverso la storia del maestro, spingendo gli oggetti 2000 alla volta. (Puoi, ovviamente, sostituire un ramo diverso in entrambi i posti, se lo desideri). Al termine, dovresti essere in grado di spingere il master un'ultima volta e le cose dovrebbero essere aggiornate. Se 2000 è troppo e si riscontra nuovamente il problema, è possibile regolare il numero in modo che sia più piccolo.

Sprecate alcune ore a provare alcune di queste soluzioni, ma alla fine lo abbiamo rintracciato in un IPS aziendale (Instrusion Protection System) interrompendo la connessione dopo il trasferimento di una determinata quantità di dati.

Per la larghezza di banda condivisa prova a clonare quando il carico è inferiore. Altrimenti, prova con una connessione ad alta velocità. Se il problema persiste, utilizzare il comando seguente,

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

E prova a clonare di nuovo. Potrebbe essere necessario modificare tali impostazioni in base alle dimensioni della memoria disponibile.

Potrebbe essere semplice come un problema del server. Se si utilizza GitHub, consultare https://twitter.com/githubstatus . L'ho visto per la prima volta proprio ora e ho scoperto che GitHub stava traballando . Pochi minuti dopo ha funzionato di nuovo bene.

Questo ha funzionato per me, impostando il nameserver di Google perché non è stato specificato alcun nameserver standard, seguito dal riavvio della rete:

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

Ho affrontato questo problema usando git in Kubuntu. Ho anche notato instabilità generale nel networking e ho trovato una soluzione .

in /etc/resolv.conf aggiungi la riga alla fine del file

opzioni a richiesta singola

Questo risolto i ritardi prima che ogni risoluzione dei nomi di dominio e git iniziassero a funzionare come un fascino dopo questo.

Ho trovato il mio problema con il file .netrc, se è così anche per te allora puoi fare quanto segue:

Apri il tuo file .netrc e modificalo per includere le credenziali github. Digitare nano ~/netrcogedit ~/netrc

Quindi includere quanto segue: * machine github.com

nome utente di accesso

password SEGRETA

macchina api.github.com

nome utente di accesso

password SEGRETA *

È possibile includere la password non elaborata lì, ma per motivi di sicurezza, generare un token di autenticazione qui token github e incollarlo al posto della password.

Spero che questo aiuti qualcuno

Potrebbe essere a causa delle dimensioni dei commit che vengono spinti. Suddividere il numero di commit mediante i seguenti passaggi:

git log -5

Vedi gli ultimi 5 commit e sapresti quali non vengono inviati al telecomando. Seleziona un ID commit e invia tutti i commit fino a quell'id:

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

NOTA: ho appena verificato il commit che potrebbe avere le dimensioni maggiori; prima sollevato fino ad allora. Il trucco ha funzionato. !!

Stavo facendo git push dal mio OS X El Capitan Mac. Stavo ottenendo lo stesso errore, ho provato di tutto per risolvere ciò che ho trovato su Google / StackOverflow. Per quanto riguarda la versione, sto usando la versione più recente di github che è 2.7.4. Ho creato un progetto nel mio sistema locale e volevo che fosse pubblico nel mio account github. La dimensione del progetto non era di circa 8 MB. Ho notato che quando stavo spingendo alcuni file di dimensioni intorno a 1,5 MB, stava spingendo correttamente, ma con grandi dimensioni fallito per me, con lo stesso errore,

L'unica opzione che avevo era quella di spingere le modifiche in blocco di MB. Ora ho spinto tutti i cambiamenti. Questa è una soluzione alternativa per me fino a quando non avrò una soluzione per questa soluzione.

Quindi puoi anche provare a spingere il cambiamento in più commit. Oppure, se hai più cartelle, puoi inviare le modifiche per ogni cartella (se la dimensione della cartella non è grande).

Spero che questo ti aiuti a continuare a lavorare sul progetto.

Di fronte allo stesso problema, prova a fonderti con un altro ramo e prendi un tiro da loro. Funziona per me stesso.

usa sshinvece di http, non è una buona risposta a questa domanda ma almeno funziona per me