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

Durante clone, fetch e push, o git o apresenta como “error: RPC failed; curl 56 GnuTLS recv error (-110): …”; durante ls-remote ou a primeira requisição, ele aparece depois de “fatal: unable to access '<url>': ”. Builds do git com OpenSSL relatam o mesmo evento como “OpenSSL SSL_read: … unexpected eof while reading”.

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

O que significa

Enquanto o git recebia dados por HTTPS, a conexão TCP foi fechada sem a mensagem TLS close_notify, que marca um encerramento correto. O GnuTLS (erro -110, GNUTLS_E_PREMATURE_TERMINATION) trata isso como uma leitura com falha, então o clone, o fetch ou o push é abortado. Os certificados estavam corretos; algo cortou a conexão no meio da transferência.

Por que acontece

• Um proxy, firewall ou gateway NAT derruba a conexão

  comum

  Proxies e firewalls corporativos com limites de tempo de conexão ou de inatividade, clientes VPN e alguns roteadores domésticos cortam transferências HTTPS longas sem um encerramento TLS.

• O servidor Git ou o proxy reverso dele atinge o tempo limite

  comum

  Repositórios grandes demoram para ser empacotados no lado do servidor. Se o nginx, o HAProxy ou um balanceador de carga na frente do GitLab, do Gitea ou do Bitbucket tem um tempo limite curto, a conexão é fechada enquanto o git ainda está esperando.

• Clones ou pushes muito grandes

  ocasional

  Repositórios com um histórico grande de binários levam as transferências a uma faixa em que todo limite de tempo ou de tamanho no caminho faz diferença. Aumentar o http.postBuffer é uma sugestão comum, mas isso só muda a forma como o git envia o corpo das requisições; não impede que a conexão seja cortada.

• Conexões de rede instáveis

  ocasional

  Roaming de Wi-Fi, internet compartilhada pelo celular e enlaces VPN congestionados podem derrubar conexões no meio da transferência; o mesmo comando então funciona numa nova tentativa ou numa conexão cabeada.

Como corrigir

1. 1.

   Rastrear a transferência

   GIT_TRACE_CURL mostra a troca HTTP com carimbos de data/hora. Uma falha depois de um número redondo de segundos indica um tempo limite; uma falha em momentos aleatórios indica a rede.

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

   Transferir menos em cada requisição

   Um clone parcial (--filter=blob:none) ou um clone raso seguido de git fetch --unshallow divide o trabalho em requisições menores, com menos chance de atingir um 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.

   Donos do servidor: aumentar os tempos limite e os limites de corpo no proxy

   Configure, no proxy reverso que fica na frente do servidor Git, tempos limite que cubram seus maiores repositórios e não limite o tamanho do corpo das requisições nos endpoints do 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.

   Usar SSH em vez de HTTPS

   Se o caminho HTTPS passa por um proxy que corta transferências e o SSH é permitido, um remoto SSH evita esse salto.

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

← Ver toda a base de erros de assinatura