GnuTLS recv error (-110): The TLS connection was non-properly terminated.

Bei clone, fetch und push verpackt git den Fehler als „error: RPC failed; curl 56 GnuTLS recv error (-110): …“; bei ls-remote oder der ersten Anfrage erscheint er nach „fatal: unable to access '<url>': “. git-Builds mit OpenSSL melden dasselbe Ereignis als „OpenSSL SSL_read: … unexpected eof while reading“.

git over HTTPS with libcurl-gnutls (Debian, Ubuntu) — GNUTLS_E_PREMATURE_TERMINATION

Was der Fehler bedeutet

Während git Daten über HTTPS empfing, wurde die TCP-Verbindung ohne die TLS-Nachricht close_notify geschlossen, die ein ordnungsgemäßes Ende markiert. GnuTLS (Fehler -110, GNUTLS_E_PREMATURE_TERMINATION) wertet das als fehlgeschlagenen Lesevorgang, deshalb bricht der Clone, Fetch oder Push ab. Die Zertifikate waren in Ordnung; irgendetwas hat die Verbindung mitten in der Übertragung gekappt.

Warum der Fehler auftritt

• Ein Proxy, eine Firewall oder ein NAT-Gateway kappt die Verbindung

  häufig

  Firmen-Proxys und Firewalls mit Limits für Verbindungsdauer oder Leerlaufzeit, VPN-Clients und manche Heimrouter kappen lang laufende HTTPS-Übertragungen ohne TLS-Shutdown.

• Der Git-Server oder sein Reverse Proxy läuft in ein Timeout

  häufig

  Große Repositorys brauchen serverseitig eine Weile zum Packen. Hat nginx, HAProxy oder ein Load Balancer vor GitLab, Gitea oder Bitbucket ein kurzes Timeout, wird die Verbindung geschlossen, während git noch wartet.

• Sehr große Clones oder Pushes

  gelegentlich

  Bei Repositorys mit großer binärer Historie erreichen Übertragungen Größenordnungen, in denen jedes Zeit- oder Größenlimit auf dem Weg ins Gewicht fällt. Oft wird empfohlen, http.postBuffer zu erhöhen, doch das ändert nur, wie git Request-Bodys sendet; es verhindert nicht, dass eine Verbindung gekappt wird.

• Instabile Netzwerkverbindungen

  gelegentlich

  WLAN-Roaming, Tethering über das Smartphone und überlastete VPN-Verbindungen können Verbindungen mitten in der Übertragung zurücksetzen; derselbe Befehl gelingt dann bei einem erneuten Versuch oder über eine kabelgebundene Verbindung.

So behebst du den Fehler

1. 1.

   Übertragung mitprotokollieren

   GIT_TRACE_CURL zeigt den HTTP-Austausch mit Zeitstempeln. Ein Abbruch nach einer runden Anzahl Sekunden deutet auf ein Timeout hin, ein Abbruch zu zufälligen Zeitpunkten auf das Netzwerk.

   # Where does the transfer stop? Time stamps show cut-offs at fixed timeouts.
   GIT_TRACE_CURL=1 GIT_TRACE_CURL_NO_DATA=1 git clone https://git.example.com/team/app.git 2>&1 | tail -40

2. 2.

   Weniger pro Anfrage übertragen

   Ein Partial Clone (--filter=blob:none) oder ein Shallow Clone mit anschließendem git fetch --unshallow teilt die Arbeit in kleinere Anfragen auf, die seltener an ein Limit stoßen.

   # Transfer less per request: shallow or partial clone, then fetch the rest
   git clone --filter=blob:none https://git.example.com/team/app.git
   git clone --depth 1 https://git.example.com/team/app.git && cd app && git fetch --unshallow

3. 3.

   Eigener Server: Proxy-Timeouts und Body-Limits erhöhen

   Gib dem Reverse Proxy vor dem Git-Server Timeouts, die auch für deine größten Repositorys reichen, und begrenze die Größe des Request-Bodys für Git-Endpunkte nicht.

   # Reverse proxy in front of the Git server (nginx), for long clones and pushes
   proxy_read_timeout 600s;
   proxy_send_timeout 600s;
   client_max_body_size 0;

4. 4.

   SSH statt HTTPS verwenden

   Führt der HTTPS-Weg über einen Proxy, der Übertragungen kappt, und ist SSH erlaubt, umgeht ein SSH-Remote diese Zwischenstation.

   # Bypass the HTTPS path (and the proxy that cuts it) entirely
   git remote set-url origin git@git.example.com:team/app.git

← Gesamte Signaturfehler-Datenbank durchsuchen