L'extrémité distante a raccroché de manière inattendue lors du clonage git

Mon gitclient échoue à plusieurs reprises avec l'erreur suivante après avoir essayé de cloner le référentiel pendant un certain temps.

Quel pourrait être le problème ici?

Remarque: j'ai enregistré ma clé SSH auprès du fournisseur d'hébergement GIT

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

Solution rapide:

Avec ce genre d'erreur, je commence généralement par augmenter la postBuffertaille en:

git config --global http.postBuffer 524288000

(certains commentaires ci-dessous indiquent qu'il faut doubler la valeur):

git config --global http.postBuffer 1048576000

Plus d'information:

Depuis la git configpage de manuel , il http.postBuffers'agit de:

Taille maximale en octets de la mémoire tampon utilisée par les transports HTTP intelligents lors du POST de données vers le système distant.
Pour les demandes supérieures à cette taille de tampon, HTTP / 1.1 et Transfer-Encoding: chunkedest utilisé pour éviter de créer un fichier de pack massif localement. La valeur par défaut est de 1 Mio, ce qui est suffisant pour la plupart des demandes.

Même pour le clone, cela peut avoir un effet, et dans ce cas, l' OP Joe rapporte:

[clone] fonctionne bien maintenant

Remarque: si quelque chose s'est mal passé côté serveur, et si le serveur utilise Git 2.5+ (Q2 2015), le message d'erreur peut être plus explicite.
Voir " Clonage Git: l'extrémité distante a raccroché de façon inattendue, a essayé de changer postBuffermais échoue toujours ".

Kulai ( dans les commentaires ) souligne cette page Atlassian de dépannage Git , qui ajoute:

Error code 56indique qu'une boucle a reçu l'erreur, CURLE_RECV_ERRORce qui signifie qu'un problème a empêché la réception des données pendant le processus de clonage.
Cela est généralement dû à un paramètre réseau, un pare-feu, un client VPN ou un antivirus qui met fin à la connexion avant que toutes les données aient été transférées.

Il mentionne également la variable d'environnement suivante, afin d'aider au processus de débogage.

# 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

Avec Git 2.25.1 (février 2020), vous en savez plus sur cette http.postBuffer"solution".

Voir commit 7a2dc95 , commit 1b13e90 (22 janvier 2020) par brian m. carlson ( bk2204) .
^{(Fusionné par Junio ​​C Hamano - gitster- dans commit 53a8329 , 30 janvier 2020)}
( discussion sur la liste de diffusion Git )

docs: mention lors de l'augmentation de http.postBuffer est précieuse

^{Signature: brian m. Carlson}

Les utilisateurs dans une grande variété de situations se retrouvent avec des problèmes de push HTTP.

Souvent, ces problèmes sont dus à un logiciel antivirus, à des proxys de filtrage ou à d'autres situations de l'homme du milieu; d'autres fois, ils sont dus à une simple non-fiabilité du réseau.

Cependant, une solution courante aux problèmes de push HTTP trouvés en ligne consiste à augmenter http.postBuffer.

Cela ne fonctionne pour aucune des situations susmentionnées et n'est utile que dans un petit nombre de cas très restreint: essentiellement, lorsque la connexion ne prend pas correctement en charge HTTP / 1.1.

Documenter quand augmenter cette valeur est approprié et ce qu'elle fait réellement, et décourager les gens de l'utiliser comme solution générale aux problèmes de poussée, car elle n'est pas efficace là-bas.

Donc, la documentation pour l' git config http.postBufferinstant comprend:

http.postBuffer

Taille maximale en octets de la mémoire tampon utilisée par les transports HTTP intelligents lors du POST de données vers le système distant.
Pour les demandes supérieures à cette taille de tampon, HTTP / 1.1 et Transfer-Encoding: chunked est utilisé pour éviter de créer localement un fichier de pack massif.
La valeur par défaut est de 1 Mio, ce qui est suffisant pour la plupart des demandes.

Notez que l'augmentation de cette limite n'est efficace que pour désactiver le codage de transfert par blocs et ne doit donc être utilisée que lorsque le serveur distant ou un proxy prend uniquement en charge HTTP / 1.0 ou n'est pas conforme à la norme HTTP.
Augmenter cela n'est pas, en général, une solution efficace pour la plupart des problèmes de push, mais peut augmenter la consommation de mémoire de manière significative car la totalité du tampon est allouée même pour les petites push .

Même erreur avec Bitbucket. Fixé par

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

L'astuce http.postBuffer n'a pas fonctionné pour moi. Toutefois:

Pour d'autres personnes rencontrant ce problème, il peut s'agir d'un problème avec GnuTLS. Si vous définissez le mode détaillé, vous pouvez voir l'erreur sous-jacente ressembler à quelque chose dans le sens du code ci-dessous.

Malheureusement, ma seule solution jusqu'à présent est d'utiliser SSH.

J'ai vu une solution publiée ailleurs pour compiler Git avec OpenSSL au lieu de GnuTLS. Il y a un rapport de bogue actif pour le problème ici .

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 .: La modification http.postBufferpeut également nécessiter la configuration du fichier de configuration Nginx pour que gitlab accepte des tailles de corps plus grandes pour le client, en ajustant la valeur de client_max_body_size.

Cependant, il existe une solution de contournement si vous avez accès à la machine Gitlab ou à une machine de son réseau, et c'est en utilisant git bundle.

1. allez dans votre dépôt git sur la machine source
2. courir git bundle create my-repo.bundle --all
3. transférer (par exemple, avec rsync) le fichier my-repo.bundle sur la machine de destination
4. sur la machine de destination, exécutez git clone my-repo.bundle
5. git remote set-url origin "path/to/your/repo.git"
6. git push

Bonne chance!

La seule chose qui a fonctionné pour moi a été de cloner le dépôt en utilisant le lien HTTPS au lieu du lien SSH .

Si vous utilisez https et que vous obtenez l'erreur.

J'ai utilisé https au lieu de http et cela a résolu mon problème

git config --global https.postBuffer 524288000

Sur la base de cette réponse , j'ai essayé de suivre (avec l'URL https):

1. clonage initial du dépôt:

git clone --depth 25 url-here

2. fetch valide avec une augmentation de deux fois par profondeur d’essai:

git fetch --depth 50

git fetch --depth 100

git fetch --depth 200

...etc

3. finalement (quand je pense qu'il y en a assez), je cours git fetch --unshallow- et c'est fait.

Le processus prend évidemment beaucoup plus de temps, mais dans mon cas, http.postBufferil core.compressionn'a pas aidé.

UPD : J'ai découvert que la récupération via ssh fonctionne pour toute taille de référentiel (découverte accidentellement), effectuée avecgit clone <ssh url> , étant donné que vous avez créé des clés ssh. Une fois le repo récupéré, je change d'adresse distante en utilisantgit remote set-url <https url to repo>

J'ai obtenu une solution après avoir utilisé la commande ci-dessous:

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

J'ai eu le même problème, j'ai corrigé cela avec la méthode d'essai et d'erreur. J'ai changé la valeur core.compression jusqu'à ce que cela fonctionne.

J'ai commencé avec "git config --global core.compression 1" après 3 tentatives

"git config --global core.compression 4" a fonctionné pour moi.

Cela est dû au problème de connectivité Internet, j'ai rencontré le même problème. J'ai fait une copie superficielle du code en utilisant

git clone --depth 1 //FORKLOCATION

Plus tard, le clone n'a pas été utilisé à l'aide

git fetch --unshallow

en /etc/resolv.confajoutant la ligne à la fin du fichier

options single-request

Eh bien, je voulais pousser une solution de 219 Mo, mais je n'ai pas eu de chance avec

git config --global http.postBuffer 524288000

Et quel est l'intérêt d'avoir une mémoire tampon de 525 Mo de toute façon? c'est idiot. J'ai donc regardé l'erreur git ci-dessous:

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

Alors git veut publier 5 Mo, puis j'ai fait le tampon de post 6 Mo, et ça marche

git config --global http.postBuffer 6291456

J'ai eu le même problème et il était lié à une mauvaise connexion Internet, donc après avoir essayé avec certaines configurations git, je viens de me déconnecter de mon réseau et de me reconnecter et cela fonctionne!.

Il semble qu'après la perte de connexion (ou l'action qui déclenche cette situation), git soit bloqué.

J'espère que cela pourrait être utile à quelqu'un de plus ici.

Meilleur,

J'ai également eu le même problème. La raison de ce problème est que les descriptions de Kurtis sur GNUTLS.

Si vous avez la même raison et que votre système est Ubuntu, vous pouvez résoudre ce problème en installant la dernière version de git à partir de ppa:git-core/ppa.Les commandes sont les suivantes.

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

J'étais confronté à ce problème lors du clonage de données (via HTTP) à partir d'un référentiel git distant hébergé sur une instance AWS EC2 gérée par élastique beanstalk. Le clonage lui-même a également été effectué sur l'instance AWS EC2.

J'ai essayé toutes les solutions susmentionnées et leurs combinaisons:

• définition de git http.postBuffer
• réglagehttp.maxrequestbuffer
• désactiver la compression git et essayer "superficiel" git clone, puis git fetch --unshallow- voir fatal: EOF fatal fatal: index-pack failed
• réglage des paramètres de mémoire GIT - packedGitLimit et al, voir ici: fatal: early EOF fatal: index-pack failed
• configuration de tunning nginx - mise client_max_body_sizeà la fois à grande valeur et 0 (illimité); réglageproxy_request_buffering off;
• réglage options single-request dans /etc/resolv.conf
• limitation du débit du client git avec un filet
• utilisation de strace pour le traçage git clone
• envisager la mise à jour du client git

Après tout cela, j'étais toujours confronté au même problème encore et encore, jusqu'à ce que je trouve que ce problème se trouve dans Elastic Load Balancer (ELB) coupant la connexion . Après avoir accédé à l'instance EC2 (celle hébergeant git repo) directement au lieu de passer par ELB, j'ai finalement réussi à cloner git repo! Je ne sais toujours pas lequel des paramètres ELB (timeout) est responsable de cela, donc je dois encore faire des recherches.

METTRE À JOUR

Il semble que la modification de la stratégie de drainage de connexion pour AWS Elastic Load Balancer en augmentant le délai d'expiration de 20 secondes à 300 secondes ait résolu ce problème pour nous.

La relation entre le git clone erreurs et le "drainage de la connexion" est étrange et pas évidente pour nous. Il se peut que le changement de délai d'expiration de la connexion ait provoqué des changements internes dans la configuration ELB qui ont résolu le problème de fermeture prématurée de la connexion.

Il s'agit de la question connexe sur le forum AWS (pas encore de réponse): https://forums.aws.amazon.com/thread.jspa?threadID=258572

J'ai eu un problème similaire, mais avec un travail de bambou. Bamboo échouait à faire un clone local (local mais sur un proxy SSH) d'un référentiel mis en cache, j'ai supprimé le cache et après cela a fonctionné, mais chaque fois qu'il essaie de cloner à partir du cache local, il y a un échec. Il semble qu'un problème avec la version de Bamboo du proxy SSH ne soit pas git en soi.

J'ai la même erreur lors de l'utilisation de BitBucket. Ce que j'ai fait, c'est supprimer https de l'URL de mon dépôt et définir l'URL à l'aide HTTP.

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

RÉSOLU AVEC le réglage du routeur WIFI:

J'ai le même problème lorsque je suis en wifi avec les paramètres PPPoE (connexion automatique par routeur wifi).

La vitesse de téléchargement de Git est très lente de 15 Ko.

packet_write_wait: connexion au port 22 de 17.121.133.16: canal interrompu fatal: l'extrémité distante a raccroché de façon inattendue: fatal EOF précoce: index-pack a échoué

Solution: 1. Modification du paramètre en IP dynamique, redémarrage du routeur wifi. 2. De la connexion du navigateur Web au portail du fournisseur de services Internet (ne configurez pas PPPoE, connexion automatique à partir du routeur wifi).

Après avoir changé la vitesse de téléchargement de Git est de 1,7 Mo.

Cela a résolu mon problème:

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

Les astuces ci-dessus ne m'ont pas aidé, car le repo était plus grand que la taille de poussée maximale autorisée sur github. Ce qui a fonctionné était une recommandation de https://github.com/git-lfs/git-lfs/issues/3758 qui a suggéré de pousser un peu à la fois:

Si votre branche a une longue histoire, vous pouvez essayer de pousser un plus petit nombre de validations à la fois (disons 2000) avec quelque chose comme ceci:

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

Cela marchera à travers l'histoire du maître, poussant les objets 2000 à la fois. (Vous pouvez, bien sûr, remplacer une branche différente aux deux endroits si vous le souhaitez.) Lorsque cela est fait, vous devriez pouvoir pousser le maître une dernière fois, et les choses devraient être à jour. Si 2000 est trop et que vous rencontrez à nouveau le problème, vous pouvez ajuster le nombre afin qu'il soit plus petit.

A gaspillé quelques heures à essayer certaines de ces solutions, mais a finalement retracé cela à un IPS (Instrusion Protection System) d'entreprise abandonnant la connexion après le transfert d'une certaine quantité de données.

Pour la bande passante partagée, essayez de cloner lorsque la charge est moindre. Sinon, essayez avec une connexion haut débit. Si cela ne fonctionne toujours pas, veuillez utiliser la commande ci-dessous,

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

Et essayez à nouveau de cloner. Vous devrez peut-être modifier ces paramètres en fonction de la taille de votre mémoire disponible.

Cela peut être aussi simple qu'un problème de serveur. Si vous utilisez GitHub, consultez https://twitter.com/githubstatus . Je l'ai vu pour la première fois tout à l'heure et j'ai découvert que GitHub avait une oscillation . Quelques minutes plus tard, cela a de nouveau bien fonctionné.

Cela a fonctionné pour moi, en configurant le serveur de noms Googles car aucun serveur de noms standard n'a été spécifié, suivi du redémarrage du réseau:

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

J'ai fait face à ce problème en utilisant git dans Kubuntu. J'ai également remarqué une instabilité générale dans la mise en réseau et trouvé une solution .

dans /etc/resolv.conf ajoutez la ligne à la fin du fichier

options demande unique

Cela a corrigé les délais avant chaque résolution de nom de domaine et git a commencé à fonctionner comme un charme après cela.

J'ai trouvé mon problème avec le fichier .netrc, si c'est le cas pour vous aussi, vous pouvez faire ce qui suit:

Ouvrez votre fichier .netrc et modifiez-le pour inclure les informations d'identification github. Tapez nano ~/netrcougedit ~/netrc

Incluez ensuite les éléments suivants: * machine github.com

nom d'utilisateur connexion

mot de passe SECRET

machine api.github.com

nom d'utilisateur connexion

mot de passe SECRET *

Vous pouvez y inclure votre mot de passe brut mais pour des raisons de sécurité, générez un jeton d'authentification ici jeton github et coller à la place de votre mot de passe.

J'espère que cela aide quelqu'un

Cela peut être dû à la taille des validations poussées. Décomposez le nombre de validations en procédant comme suit:

git log -5

Voir les 5 derniers commits et vous saurez lesquels ne sont pas poussés à distance. Sélectionnez un ID de validation et poussez toutes les validations jusqu'à cet ID:

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

REMARQUE: je viens de vérifier mon commit qui pourrait avoir la plus grande taille; d'abord poussé jusque-là. L'astuce a fonctionné. !!

Je faisais git push depuis mon Mac OS X El Capitan. J'obtenais la même erreur, j'ai tout essayé pour réparer, ce que j'ai trouvé sur google / stackoverflow. En ce qui concerne la version, j'utilise une version assez récente de github qui est 2.7.4. J'ai créé un projet dans mon système local, et je voulais qu'il soit public dans mon compte github. La taille du projet n'était pas d'environ 8 Mo. J'ai remarqué que lorsque je poussais certains fichiers d'une taille d'environ 1,5 Mo, il poussait correctement, mais avec une grande taille, j'ai échoué, avec la même erreur,

La seule option que j'avais était de pousser les changements dans un morceau de Mo. Maintenant, j'ai poussé tous les changements. C'est une solution de contournement pour moi jusqu'à ce que je trouve une solution pour cette solution.

Vous pouvez donc également essayer de pousser le changement dans plusieurs validations. Ou si vous avez plusieurs dossiers, vous pouvez pousser les modifications par chaque dossier (si la taille du dossier n'est pas grande).

J'espère que cela vous aidera à travailler en continu sur le projet.

Face au même problème, essayez de fusionner avec une autre branche et tirez dessus. Cela fonctionne pour moi de la même façon.

utiliser à la sshplace de http, ce n'est pas une bonne réponse à cette question mais au moins ça marche pour moi