git clone endet mit Broken Pipe

Habe ich ein sehr großes git-repository und möchten Klon von ihm. Auf einer Maschine (ArchLinux mit git-version 2.2.2) funktioniert alles einwandfrei...

Cloning into 'foo'
remote: Counting objects: 2372505, done
remote: Compressing objects: 100% (456914/456914), done.
Receiving objects: 100% (2372505/2372505), 3.81 GiB | 6.20 MiB/s, done.
...

... aber auf einem anderen Rechner (Ubuntu mit git version 2.3.0, habe auch versucht mit 1.7.0.4), sehe ich nur die folgenden:

Cloning into 'foo'
remote: Counting objects: 2372505, done.

sich nach einigen Stunden, es endet mit

Write failed: Broken pipe
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Eine Idee, was das problem ist?

Übrigens:

  • Das remote-Ende ist ein gitlab server.
  • Ich bin mit SSH in beiden Fällen.
  • Der erste (Arbeits -) Maschine ist, die über VPN verbunden (100 MBit/s).
  • Die zweite (nicht funktionierende) Maschine ist in der gleichen gigabit-Subnetz wie der gitlab-server.
  • Sind Sie hinter einer firewall? Weil die firewall manchmal bricht die Kommunikation, dass die Ergebnisse in diesem. Ich weiß nicht, wie und warum. BTW, welche version von git verwenden Sie?
  • Nein. Wie bereits erwähnt: Der client ist im selben Subnetz wie der server. Ich dachte auch, es könnte ein problem mit den alten git-version (1.7.0.4), aber nach einem upgrade auf 2.3.0 das problem ist immer noch da.
  • Funktioniert diese Hilfe? hungred.com/how-to/gitlab-error-fatal-remote-hung-unexpectedly
  • Dies ist ein weiteres problem. Ich hatte auch diese nach der Installation von gitlab vor einem Jahr, aber ich habe es schon behoben dann zurück.
InformationsquelleAutor Ethan Leroy | 2015-02-09
  1. 2

    Gelöst! Ich verwendet ein DNS-name für die Verbindung zum gitlab server, und was ich nicht wusste: Dieser name wurde behoben und die externe IP von dem gleichen server, also der server und der client nicht im gleichen Subnetz.

    So, die Clients mit der externen IP des Servers, also musste die firewall NAT es wieder zurück an den server.

    Die Lösung war ganz einfach: habe ich nur noch den Hostnamen mit der internen ip auf der client-Maschine /etc/hosts - Datei, und der Klon funktionierte wie ein Charme.

    • Tollen Fang, präziser als meine Antwort. +1
    • Ja. War mein Fehler, weil die Frage falsch war. Aber danke für deine Hilfe!
    • Kein problem: es wird hoffentlich anderen zu helfen, wie gut.
    InformationsquelleAutor Ethan Leroy
  2. 1

    Über GitLab, dieser thread erwähnt (für eine ähnliche Fehlermeldung)

    Löste ich das Problem (nicht zur Kasse großes repo' via HTTP), durch Bearbeiten git/config/unicorn.yml und timeout auf 120, wenn Sie vorher war 30, und starten Sie die gitab service.

    Ob dies nicht nur über das Git-hosting-server, sondern über Git selbst, dann haben Sie andere Optionen, um zu versuchen:

    • Ich bin nicht mit HTTP zur Kasse. Außerdem, ich glaube nicht, dass es, verursacht durch gitlab, da ich in der Lage bin zu Klonen, das repo mit anderen Maschinen.
    • wie über einige lokale Git config dann (help.openshift.com/hc/en-us/articles/...): git config pack.windowMemory 10m && git config pack.packSizeLimit 20m
    • ein weiterer Ansatz, nur zum testen: git in it && git remote add origin <ssh/url/of/gitlab/repo> && git pull origin master
    • mit remote add: Gute Idee, aber dasselbe problem.
    • mit config pack...: Wow! Jetzt tut es auch Compressing objects und beginnt Receiving objects, aber es stecken bei 3%. Was bedeutet es?
    • vielleicht die ssh-Verbindung ist nicht widerstandsfähig genug für diese operation? (wie in stackoverflow.com/a/17494901/6309)
    • Ich ServerAliveInterval auf 60, aber das macht keinen Unterschied.

    InformationsquelleAutor VonC
  3. 0

    Für mich, nach dem Versuch alle Vorschläge im Netz gefunden, es stellte sich heraus, dass die VPN-Verbindung wurde die Verbindung und Trennung ständig. Es scheint, dass, wenn es zu viele "Netzwerk-Ausfälle" oder einem verlustbehafteten Netzwerk, git clone "jams" und schließlich bekommen Sie die Broken pipe-Fehler-Meldung.

    Debuggen, wenn es irgendwelche realen Verkehr geht, können Sie

    iptraf

    oder 

    tcpdump -ni eth0 host github.com

    In meinem Fall, gab es zunächst einen stetigen Fluss von 2MB/s, aber nach ein paar Sekunden die zugrunde liegende Verbindung brach ab, und die Klon-stream nie wieder erholt, bis ich der festen OpenVPN-Verbindung zu bleiben stabiler.

    InformationsquelleAutor PHZ.fi-Pharazon
Schreibe einen Kommentar