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

Lors d’un clone, d’un fetch ou d’un push, git l’affiche sous la forme « error: RPC failed; curl 56 GnuTLS recv error (-110): … » ; lors d’un ls-remote ou de la première requête, l’erreur apparaît après « fatal: unable to access '<url>': ». Les builds de git reposant sur OpenSSL signalent le même événement par « OpenSSL SSL_read: … unexpected eof while reading ».

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

Ce que cela signifie

Pendant que git recevait des données en HTTPS, la connexion TCP s’est fermée sans le message TLS close_notify qui marque une fin en bonne et due forme. GnuTLS (erreur -110, GNUTLS_E_PREMATURE_TERMINATION) traite cela comme un échec de lecture : le clone, le fetch ou le push est donc interrompu. Les certificats étaient corrects ; quelque chose a coupé la connexion en plein transfert.

Pourquoi cela se produit

• Un proxy, un pare-feu ou une passerelle NAT coupe la connexion

  fréquente

  Les proxys et pare-feu d’entreprise qui limitent la durée de connexion ou d’inactivité, les clients VPN et certains routeurs domestiques coupent les transferts HTTPS de longue durée sans fermeture TLS.

• Le serveur Git ou son proxy inverse atteint son délai d’expiration

  fréquente

  Côté serveur, l’empaquetage des gros dépôts prend du temps. Si nginx, HAProxy ou un répartiteur de charge placé devant GitLab, Gitea ou Bitbucket a un délai d’expiration court, la connexion est fermée alors que git attend encore.

• Clones ou push très volumineux

  occasionnelle

  Les dépôts dont l’historique contient de gros fichiers binaires produisent des transferts assez volumineux pour que chaque limite de durée ou de taille sur le chemin compte. Augmenter http.postBuffer est une suggestion courante, mais cela change seulement la façon dont git envoie le corps des requêtes ; cela n’empêche pas la coupure d’une connexion.

• Liaisons réseau instables

  occasionnelle

  L’itinérance Wi-Fi, le partage de connexion mobile et les liaisons VPN saturées peuvent réinitialiser les connexions en plein transfert ; la même commande réussit alors quand vous la relancez, ou sur une connexion filaire.

Comment corriger l’erreur

1. 1.

   Tracer le transfert

   GIT_TRACE_CURL affiche l’échange HTTP horodaté. Un échec après un nombre rond de secondes indique un délai d’expiration ; un échec à un moment aléatoire désigne le réseau.

   # 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.

   Transférer moins de données par requête

   Un clone partiel (--filter=blob:none) ou un clone superficiel suivi de git fetch --unshallow découpe le travail en requêtes plus petites, moins susceptibles d’atteindre une limite.

   # 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.

   Propriétaires de serveurs : augmenter les délais d’expiration du proxy et les limites de taille du corps

   Donnez au proxy inverse placé devant le serveur Git des délais d’expiration suffisants pour vos plus gros dépôts, et ne limitez pas la taille du corps des requêtes pour les points de terminaison Git.

   # 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.

   Utiliser SSH au lieu de HTTPS

   Si le chemin HTTPS passe par un proxy qui coupe les transferts et que SSH est autorisé, un dépôt distant configuré en SSH évite ce maillon.

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

← Parcourir toute la base de données des erreurs de signature