Дистанционный конец неожиданно зависал во время клонирования 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

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

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

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

Answer 2

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

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

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

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

UPDATE

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

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

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

Answer 3

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

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

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

Best,

Answer 4

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

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

Answer 5

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

git clone --depth 1 //FORKLOCATION

Позже отменил клон, используя

git fetch --unshallow

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

РЕШЕНО С WIFI Маршрутизатор Настройка:

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

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

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

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

После изменения скорости загрузки Git 1.7MiB.

Answer 10

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

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

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

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