Удаленный конец неожиданно повесил трубку, пока git клонирование

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

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

Error code 56 указывает, что curl получает ошибку 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

Ответ 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

Ответ 3

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

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

Ответ 4

Ни один из вышеперечисленных не работал у меня, но вот что сделал: fooobar.com/questions/37810/...

Полное сообщение об ошибке, которое я получал, было:

fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Ответ 5

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

Однако существует обходной путь, если у вас есть доступ к машине Gitlab или к машине в своей сети, и это делается с помощью git bundle.

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

Все самое лучшее!

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

git config --global https.postBuffer 524288000

Ответ 9

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

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

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

Ответ 10

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

options single-request

Ответ 11

Ну, я хотел нажать 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

Ответ 12

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

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

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

Ответ 13

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

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

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

Ответ 14

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

git clone --depth 1 //FORKLOCATION

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

git fetch --unshallow

Ответ 15

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

Ответ 16

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

git remote set-url origin http://[email protected]/mj/pt.git

Ответ 17

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

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

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

Бест,

Ответ 18

Основываясь на этом ответе, я попытался следующее (с 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 достаточно), я запускаю git fetch --unshallow - и все готово.

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

Ответ 19

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

Ответ 20

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

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

Ответ 21

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

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

опции с одним запросом

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

Ответ 22

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

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

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

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

Ответ 23

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

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

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

имя пользователя для входа в систему

пароль SECRET

машина api.github.com

имя пользователя для входа в систему

пароль SECRET *

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

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

Ответ 24

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

git log -5

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

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

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

Ответ 25

РЕШЕНО С настройкой 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 МБ.

Ответ 26

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

Ответ 27

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

Ответ 28

У меня была та же проблема, и я искал решение по сети. Я обнаружил, что наша корпоративная маршрутизация в IPv6 не поддерживается.

Я отключаю (опция IPv6 на порту Ethernet в Windows 10), и нет никаких проблем.

Ответ 29

Ни одно из предложенных решений не помогло мне при клонировании хранилища с помощью ssh. Тем не менее, я смог клонировать, используя https, а затем изменил пульт на ssh через:

git remote set-url origin [email protected]:USERNAME/REPOSITORY.git

Ответ 30

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

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