Die Gegenstelle hat sich beim Klonen von Git unerwartet aufgehängt

Question

Meine git Client schlägt wiederholt mit der folgenden Fehlermeldung fehl, nachdem er einige Zeit lang versucht hat, das Repository zu klonen.

Woran könnte das liegen?

Anmerkung: Ich habe meinen SSH-Schlüssel bei meinem GIT-Hosting-Anbieter registriert

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

Answer 1

Ich habe das gleiche Problem, Ich habe das Problem mit der Trial-and-Error-Methode gelöst. Ich änderte den core.compression-Wert, bis es funktioniert.

Ich begann mit "git config --global core.compression 1" nach 3 Versuchen

"git config --global core.compression 4" hat bei mir funktioniert.

Answer 2

Ich stand vor diesem Problem beim Klonen von Daten (über HTTP) aus einem entfernten Git-Repository, das auf einer von Elastic Beanstalk verwalteten AWS EC2-Instanz gehostet wird. Das Klonen selbst wurde ebenfalls auf einer AWS EC2-Instanz durchgeführt.

Ich habe alle vorgenannten Lösungen und ihre Kombinationen ausprobiert:

• Einstellung der Git http.postBuffer
• Einstellung http.maxrequestbuffer
• Ausschalten der Git-Kompression und Ausprobieren von "shallow". git clone und dann git fetch --unshallow - siehe fatal: early EOF fatal: index-pack fehlgeschlagen
• Einstellung des GIT-Speichers - packedGitLimit et al, siehe hier: fatal: early EOF fatal: index-pack fehlgeschlagen
• nginx-Konfiguration anpassen - Einstellung client_max_body_size sowohl auf den großen Wert als auch auf 0 (unbegrenzt); die Einstellung proxy_request_buffering off;
• Einstellung options single-request in /etc/resolv.conf
• Drosselung des Git-Client-Durchsatzes mit tröpfeln
• Strace für die Verfolgung verwenden git clone
• Überlegungen zur Aktualisierung des Git-Clients

Nach all dem stand ich immer wieder vor demselben Problem, bis Ich habe festgestellt, dass das Problem im Elastic Load Balancer (ELB) liegt, der die Verbindung unterbricht . Nach dem Zugriff auf die EC2-Instanz (diejenige, die das Git-Repositorium hostet) direkt, anstatt über ELB zu gehen, habe ich es endlich geschafft, das Git-Repositorium zu klonen! Ich bin mir immer noch nicht sicher, welcher der ELB-Parameter (Timeout) dafür verantwortlich ist, also muss ich noch etwas nachforschen.

UPDATE

Es scheint, dass die Änderung Anschluss Entwässerungspolitik für AWS Elastic Load Balancer durch Erhöhen der Zeitüberschreitung von 20 Sekunden auf 300 Sekunden hat dieses Problem für uns gelöst.

Die Beziehung zwischen dem git clone Fehler und "Verbindungsabbrüche" sind seltsam und für uns nicht offensichtlich. Es könnte sein, dass die Änderung des Timeouts für den Verbindungsabbau einige interne Änderungen in der ELB-Konfiguration verursacht hat, die das Problem mit dem vorzeitigen Schließen der Verbindung behoben haben.

Dies ist die entsprechende Frage im AWS-Forum (noch keine Antwort): https://forums.aws.amazon.com/thread.jspa?threadID=258572

Answer 3

Nun, ich wollte eine 219-MB-Lösung vorantreiben, aber ich hatte kein Glück mit

git config --global http.postBuffer 524288000

Und wozu braucht man überhaupt einen 525 MB großen Postpuffer? das ist doch albern. Also habe ich mir den Git-Fehler unten angesehen:

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

Git will also 5 MB posten, dann habe ich den Postpuffer auf 6 MB gesetzt, und es funktioniert

git config --global http.postBuffer 6291456

Answer 4

Ich hatte das gleiche Problem und es war im Zusammenhang mit einer schlechten Internet-Verbindung, so nach versuchen mit einigen Git-Konfigurationen, ich habe gerade von meinem Netzwerk getrennt und wieder angeschlossen und es funktioniert!

Es scheint, dass nach dem Verlust der Verbindung (oder der Aktion, die diese Situation auslöst), Git stecken bleibt.

Ich hoffe, dass es für jemanden hier eine Hilfe sein kann.

Das Beste,

Answer 5

Ich habe einige Stunden damit verbracht, einige dieser Lösungen auszuprobieren, konnte aber schließlich feststellen, dass das IPS (Instrusion Protection System) des Unternehmens die Verbindung nach einer bestimmten Datenmenge unterbricht.