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

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

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

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

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

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

С такой ошибкой я обычно начинаю с увеличения 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+ (Q2 2015), сообщение об ошибке может быть более явным.
См. « Клонирование Git: удаленный конец неожиданно завис, попытался изменить, postBufferно все еще не работает ».

Кулай ( в комментариях ) указывает на эту страницу 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

С Git 2.25.1 (февраль 2020 г.) вы узнаете больше об этом http.postBuffer«решении».

Смотрите коммит 7a2dc95 , коммит 1b13e90 (22 января 2020 г.) по Брайану м. Карлсон ( bk2204) .
^{(Объединено с Junio ​​C Hamano - gitster- в коммите 53a8329 , 30 января 2020 г.)}
( обсуждение списка рассылки Git )

docs: упоминание при увеличении http.postBuffer является ценным

^{Подписано: Брайан М. Карлсон}

Пользователи в самых разных ситуациях сталкиваются с проблемами HTTP push.

Часто эти проблемы связаны с антивирусным программным обеспечением, фильтрацией прокси-серверов или другими ситуациями «человек посередине»; в других случаях это связано с простой ненадежностью сети.

Тем не менее, распространенное решение проблем HTTP push, найденных в сети, заключается в увеличении http.postBuffer.

Это не работает ни в одной из вышеупомянутых ситуаций и полезно только в небольшом, крайне ограниченном числе случаев: по существу, когда соединение не поддерживает должным образом HTTP / 1.1.

Документируйте, когда поднимаете это значение, и то, что оно на самом деле делает, и отговаривайте людей использовать его в качестве общего решения проблем толчка, поскольку оно там неэффективно.

Итак, документация на git config http.postBufferданный момент включает в себя:

http.postBuffer

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

Обратите внимание, что повышение этого предела эффективно только для отключения кодирования передачи по частям и поэтому должно использоваться только в том случае, если удаленный сервер или прокси-сервер поддерживает только HTTP / 1.0 или несовместим со стандартом HTTP.
Поднятие этого, в общем, не является эффективным решением для большинства проблем push, но может значительно увеличить потребление памяти, так как весь буфер выделяется даже для небольших push .

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

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

Уловка 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

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

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

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

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

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

git config --global https.postBuffer 524288000

Основываясь на этом ответе , я попытался следующее (с https URL):

1. начальное клонирование репо:

git clone --depth 25 url-here

2. fetch фиксирует увеличение в два раза на глубину попытки:

git fetch --depth 50

git fetch --depth 100

git fetch --depth 200

...и так далее

3. в конце концов (когда я думаю, что достаточно извлечено) я бегу git fetch --unshallow- и все готово.

Процесс явно занимает гораздо больше времени, но в моем случае настройка http.postBufferи core.compressionне помогла.

UPD : я обнаружил, что выборка через ssh работает для любого размера репо (обнаруженного случайно), с git clone <ssh url>учетом того, что вы создали ключи ssh. После получения репо я меняю удаленный адрес, используяgit remote set-url <https url to repo>

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

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

Я получил ту же проблему, я исправил это методом проб и ошибок. Я изменил значение core.compression, пока оно не заработало.

Я начал с "git config --global core.compression 1" после 3 попыток

"git config --global core.compression 4" работал для меня.

Это связано с проблемой подключения к интернету, я столкнулся с той же проблемой. Я сделал мелкую копию кода, используя

git clone --depth 1 //FORKLOCATION

Позже отменили клон с помощью

git fetch --unshallow

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

options single-request

Ну, я хотел выдвинуть решение на 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

Так что мерзавец хочет опубликовать 5 МБ, затем я сделал буфер поста 6 МБ, и это работает

git config --global http.postBuffer 6291456

У меня была та же проблема, и она была связана с плохим подключением к Интернету, поэтому после попытки с некоторыми git-конфигами я просто отключился от своей сети и подключился снова, и это работает !.

Кажется, что после потери соединения (или действия, которое вызывает эту ситуацию), git застревает.

Я надеюсь, что это могло бы помочь кому-то еще здесь.

Лучший,

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

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

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

Я столкнулся с этой проблемой при клонировании данных (через HTTP) из удаленного репозитория git, размещенного на экземпляре AWS EC2, управляемом эластичным beanstalk. Само клонирование было также выполнено на экземпляре AWS EC2.

Я перепробовал все вышеперечисленные решения и их комбинации:

• настройка мерзавца http.postBuffer
• установкаhttp.maxrequestbuffer
• отключение сжатия git и попытка "мелкого", git cloneа затем git fetch --unshallow- увидеть фатальный: рано EOF фатальный: сбой индекса
• настройка параметров памяти GIT - packedGitLimit и др., смотрите здесь: fatal: ранний EOF fatal: index-pack не удалось
• настройка конфигурации nginx - установка client_max_body_sizeбольшого значения и 0 (неограниченно); установкаproxy_request_buffering off;
• установка options single-request в /etc/resolv.conf
• дросселировании GIT клиента пропускной способности с струйкой
• используя strace для отслеживания git clone
• учитывая обновление клиента git

После всего этого я снова и снова сталкивался с одной и той же проблемой, пока не обнаружил, что проблема заключается в том, что Elastic Load Balancer (ELB) разрывает соединение . После прямого доступа к экземпляру EC2 (тот, на котором размещается git-репо), вместо того, чтобы проходить через ELB, мне наконец-то удалось клонировать git-репо! Я до сих пор не уверен, какой из параметров ELB (тайм-аут) отвечает за это, поэтому мне все еще нужно провести некоторое исследование.

ОБНОВИТЬ

Похоже, что изменение политики опустошения подключений для AWS Elastic Load Balancer путем увеличения времени ожидания с 20 до 300 секунд решило эту проблему для нас.

Связь между git cloneошибками и «истощением связи» странная и не очевидная для нас. Возможно, изменение времени ожидания истощения соединения вызвало некоторые внутренние изменения в конфигурации ELB, которые устранили проблему с преждевременным закрытием соединения.

Это связанный вопрос на форуме AWS (пока нет ответа): https://forums.aws.amazon.com/thread.jspa?threadID=258572

У меня была похожая проблема, но с бамбуковой работой. Bamboo не удалось выполнить локальный клон (локальный, но через прокси-сервер SSH) из кэшированного репозитория, я удалил кеш, и после этого он работал, но каждый раз, когда он пытается клонировать из локального кеша, происходит сбой. Похоже, проблема с бамбуковой версией SSH-прокси, а не мерзавцем как таковым.

У меня та же ошибка при использовании BitBucket. Что я сделал, так это удалил https из URL моего репо и установил URL используя HTTP.

git remote set-url origin http://mj@bitbucket.org/mj/pt.git

РЕШЕНО С настройкой WIFI Router:

Я получил ту же проблему, когда я нахожусь в Wi-Fi с настройками PPPoE (автоматический вход через маршрутизатор Wi-Fi).

Скорость загрузки Git очень низкая 15kb.

packet_write_wait: Соединение с портом 22 17.121.133.16: неработающий канал неисправен: удаленный конец зависает неожиданно неработоспособно: рано EOF фатально: сбой index-pack

Решение: 1. Изменили настройку на Динамический IP, перезагрузите маршрутизатор Wi-Fi. 2. Из веб-браузера войдите на портал интернет-провайдера (не настраивайте PPPoE, автоматический вход с Wi-Fi-роутера).

После изменения Git скорость загрузки составляет 1,7 МБ.

Это решило мою проблему:

git clone --depth=20 https://repo.git -b master

Приведенные выше уловки мне не помогли, так как репо было больше, чем максимальный размер пуша, разрешенный на github. Что сработало, так это рекомендация от https://github.com/git-lfs/git-lfs/issues/3758, в которой предлагалось немного подтолкнуть за раз:

Если ваша ветка имеет длинную историю, вы можете попробовать выдавать меньшее количество коммитов за раз (скажем, 2000) примерно так:

git rev-list --reverse master | ruby -ne 'i ||= 0; i += 1; puts $_ if i % 2000 == 0' | xargs -I{} git push origin +{}:refs/heads/master

Это будет проходить через историю мастера, толкая объекты по 2000 за раз. (Конечно, вы можете заменить другую ветку в обоих местах, если хотите.) Когда это будет сделано, вы сможете использовать мастер в последний раз, и все должно быть в курсе. Если 2000 слишком много, и вы снова столкнулись с проблемой, вы можете отрегулировать число так, чтобы оно было меньше.

Потратив несколько часов, пытаясь использовать некоторые из этих решений, в конечном итоге это привело к тому, что корпоративная IPS (Instrusion Protection System) разорвала соединение после передачи определенного объема данных.

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

git config --global http.postBuffer 2048M
git config --global http.maxRequestBuffer 1024M
git config --global core.compression 9

git config --global ssh.postBuffer 2048M
git config --global ssh.maxRequestBuffer 1024M

git config --global pack.windowMemory 256m 
git config --global pack.packSizeLimit 256m

И попробуйте снова клонировать. Возможно, вам придется изменить эти настройки в соответствии с доступным объемом памяти.

Это может быть так же просто, как проблема с сервером. Если вы используете GitHub, проверьте https://twitter.com/githubstatus . Я впервые увидел это и обнаружил, что GitHub испытывает колебания . Через несколько минут все снова заработало.

Это сработало для меня, настроив сервер имен Googles, потому что не был указан стандартный сервер имен, а затем перезапустил сеть:

sudo echo "dns-nameservers 8.8.8.8" >> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0

Я столкнулся с этой проблемой, используя git в Kubuntu. Я также заметил общую нестабильность в сети и нашел решение .

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

варианты одиночного запроса

Это исправило задержки перед каждым разрешением доменного имени, и после этого git начал работать как чудо.

Я обнаружил, что моя проблема связана с файлом .netrc, если это так и для вас, то вы можете сделать следующее:

Откройте файл .netrc и отредактируйте его, чтобы включить учетные данные github. Тип nano ~/netrcилиgedit ~/netrc

Затем включите следующее: * машина github.com

логин

СЕКРЕТ пароля

машина api.github.com

логин

СЕКРЕТ пароля

Вы можете включить свой необработанный пароль туда, но в целях безопасности, сгенерируйте здесь токен авторизации, github и вставьте его вместо своего пароля.

Надеюсь, это поможет кому-то

Это может быть из-за размера коммитов, которые выдвигаются .. Разбейте количество коммитов следующим образом:

git log -5

Посмотрите последние 5 коммитов, и вы узнаете, какие из них не отправлены на удаленный доступ. Выберите идентификатор фиксации и нажмите все коммиты до этого идентификатора:

git push <remote_name> <commit_id>:<branch_name>

ПРИМЕЧАНИЕ: я только что проверил свой коммит, который может иметь самый большой размер; сначала толкнул до тех пор. Трюк сработал. !!

Я делал git push с моего OS X El Capitan Mac. Я получал ту же ошибку, я пытался все исправить, что я нашел в google / stackoverflow. Что касается версии, я использую довольно последнюю версию github, которая является 2.7.4. Я создал проект в своей локальной системе, и я хотел, чтобы это было публично в моей учетной записи на github. Размер проекта не был около 8 МБ. Я заметил, что когда я выдвигал некоторые файлы размером около 1,5 МБ, он выдвигался правильно, но с большим размером мне не удалось, с той же ошибкой,

Единственный вариант, который у меня был, - это выдвигать изменения в кусках МБ. Теперь я подтолкнул все изменения. Это обходной путь для меня, пока я не исправлю это решение.

Таким образом, вы также можете попробовать внести изменения в несколько коммитов. Или, если у вас есть несколько папок, вы можете вносить изменения в каждой папке (если размер папки не большой).

Надеюсь, это поможет вам продолжить работу над проектом.

Столкнулся с той же проблемой, попробуйте слиться с другой веткой и вытащить из них. У меня это работает так же.

используйте sshвместо http, это не очень хороший ответ на этот вопрос, но, по крайней мере, он работает для меня