Дистанционный конец неожиданно зависал во время клонирования git

Question

Мой git клиент несколько раз терпит неудачу со следующей ошибкой после попытки клонировать хранилище в течение некоторого времени.

В чем здесь может быть проблема?

Примечание: Я зарегистрировал свой SSH-ключ у хостинг-провайдера GIT

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

Answer 1

Быстрое решение:

С такой ошибкой я обычно начинаю с увеличения размера postBuffer на:

git config --global http.postBuffer 524288000

(некоторые комментарии ниже сообщают о необходимости удвоить значение):

git config --global http.postBuffer 1048576000

Дополнительная информация:

Из справочной страницы git config , http.postBuffer о:

Максимальный размер в байтах буфера, используемого интеллектуальными HTTP-транспортами при отправке данных в удаленную систему.
Для запросов, превышающих этот размер буфера, HTTP / 1.1 и Transfer-Encoding: chunked используются, чтобы избежать локального создания файла большого пакета. По умолчанию 1 МБ, что достаточно для большинства запросов.

Даже для клона, который может иметь эффект, и в этом случае OP Joe сообщает:

[клон] теперь отлично работает

---

Примечание: если что-то пошло не так на стороне сервера, и если сервер использует Git 2.5+ (2 квартал 2015 года), сообщение об ошибке может быть более явным.
См. " Git cloning: удаленный конец неожиданно завис, попытался изменить postBuffer, но все еще не удалось ".

---

Kulai ( в комментариях ) указывает на эту страницу Git для устранения неполадок Atlassian , которая добавляет:

Error code 56 указывает на ошибку получения скручивания CURLE_RECV_ERROR, что означает, что возникла какая-то проблема, препятствовавшая получению данных в процессе клонирования.
Обычно это вызвано сетевыми настройками, брандмауэром, VPN-клиентом или антивирусом, который завершает соединение до того, как все данные были переданы.

Также упоминается следующая переменная среды, чтобы помочь с процессом отладки.

# Linux
export GIT_TRACE_PACKET=1
export GIT_TRACE=1
export GIT_CURL_VERBOSE=1

#Windows
set GIT_TRACE_PACKET=1
set GIT_TRACE=1
set GIT_CURL_VERBOSE=1

Answer 2

Уловка http.postBuffer не работает для меня. Тем не менее:

Для других, сталкивающихся с этой проблемой, это может быть проблема с GnuTLS. Если вы установите режим Verbose, вы можете увидеть, что основная ошибка выглядит примерно так, как показано ниже:

К сожалению, пока мое единственное решение - использовать SSH.

Я видел решение, опубликованное в другом месте для компиляции Git с OpenSSL вместо GnuTLS. Активное сообщение об ошибке для проблемы здесь .

GIT_CURL_VERBOSE=1 git clone https://github.com/django/django.git

Cloning into 'django'...
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.131... * Connected to github.com (192.30.252.131) port 443 (#0)
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
*    server certificate verification OK
*    common name: github.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: 
*    start date: Mon, 10 Jun 2013 00:00:00 GMT
*    expire date: Wed, 02 Sep 2015 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV CA-1
*    compression: NULL
*    cipher: ARCFOUR-128
*    MAC: SHA1
> GET /django/django.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.8.4
Host: github.com
Accept: */*
Accept-Encoding: gzip

Pragma: no-cache
< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Thu, 10 Oct 2013 03:28:14 GMT

< Content-Type: application/x-git-upload-pack-advertisement
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
< 
* Connection #0 to host github.com left intact
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.131... * connected
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
* SSL re-using session ID
*    server certificate verification OK
*    common name: github.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: 
*    start date: Mon, 10 Jun 2013 00:00:00 GMT
*    expire date: Wed, 02 Sep 2015 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV CA-1
*    compression: NULL
*    cipher: ARCFOUR-128
*    MAC: SHA1
> POST /django/django.git/git-upload-pack HTTP/1.1
User-Agent: git/1.8.4
Host: github.com
Accept-Encoding: gzip

Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Content-Encoding: gzip
Content-Length: 2299
* upload completely sent off: 2299out of 2299 bytes

< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Thu, 10 Oct 2013 03:28:15 GMT

< Content-Type: application/x-git-upload-pack-result
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
< 
remote: Counting objects: 232015, done.
remote: Compressing objects: 100% (65437/65437), done.
* GnuTLS recv error (-9): A TLS packet with unexpected length was received.
* Closing connection #0
error: RPC failed; result=56, HTTP code = 200
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Answer 3

Та же ошибка с Bitbucket. Исправлено

git config --global http.postBuffer 500M
git config --global http.maxRequestBuffer 100M
git config --global core.compression 0

Answer 4

Obs .: При изменении http.postBuffer может также потребоваться настроить файл конфигурации Nginx для gitlab для приема больших размеров тела для клиента, настроив значение client_max_body_size.

Однако естьЭто обходной путь, если у вас есть доступ к компьютеру Gitlab или к компьютеру в его сети, то есть, используя git bundle.

1. , перейдите в свой репозиторий git на исходном компьютере.машина
2. запустить git bundle create my-repo.bundle --all
3. передать (например, с помощью rsync) файл my-repo.bundle на машину назначения
4. на машине назначения, запустить git clone my-repo.bundle
5. git remote set-url origin "path/to/your/repo.git"
6. git push

Всего наилучшего!

Answer 5

Я получил решение после использования следующей команды:

git repack -a -f -d --window=250 --depth=250

Answer 6

Единственное, что мне помогло, - это клонировать репо, используя ссылку HTTPS вместо ссылки SSH .

Answer 7

Если вы используете https и получаете сообщение об ошибке.

Я использовал https вместо http, и это решило мою проблему

git config --global https.postBuffer 524288000

Answer 8

в /etc/resolv.conf добавить строку в конец файла

options single-request

Answer 9

У меня тоже была такая же проблема. Причина этой проблемы в описании Куртиса о GNUTLS.

Если у вас та же причина, и ваша система - Ubuntu, вы можете решить эту проблему, установив последнюю версию git из ppa:git-core/ppa. Команды приведены ниже.

sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get git

Answer 10

Ну, я хотел использовать решение на 219 МБ, но мне не повезло с

git config --global http.postBuffer 524288000

И какой смысл в 525 МБ после буфера в любом случае?это глупо.Итак, я посмотрел на ошибку git ниже:

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 хочет опубликовать 5 МБ, затем я сделал буфер записи 6 МБ, и он работает

git config --global http.postBuffer 6291456