Віддалений кінець несподівано завис під час клонування 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сторінці man , http.postBufferйдеться про:

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

Навіть для клону це може мати ефект, і в цьому випадку ОП Джо повідомляє:

[клон] зараз добре працює

Примітка. Якщо на сервері щось пішло не так, і якщо сервер використовує Git 2.5+ (Q2 2015), повідомлення про помилку може бути більш явним.
Див. " Клонування Git: віддалений кінець зненацька завис, спробував змінити, postBufferале все-таки не вдалося ".

Кулай ( у коментарях ) вказує на цю сторінку Git з усунення неполадок в Атласі , яка додає:

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 р.) Від Брайана m. Карлсон ( bk2204) .
^{(Об'єднано Хуніо С Хамано - gitster- у комітеті 53a8329 , 30 січня 2020 р.)}
( Обговорення списку Git Mailing list )

docs: згадка, коли збільшення http.postBuffer є цінним

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

Користувачі у найрізноманітніших ситуаціях стикаються з проблемами HTTP push.

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

Тим не менш, поширене рішення проблем HTTP-натиску, знайдених в Інтернеті, - це збільшити http.postBuffer.

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

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

Тож документація git config http.postBufferнаразі включає:

http.postBuffer

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

Зауважте, що підвищення цього ліміту є ефективним лише для відключення кодування перенесеного перенесення, і тому його слід використовувати лише там, де віддалений сервер або проксі підтримує лише HTTP / 1.0 або не відповідають стандарту HTTP.
Підвищення цього не є, як правило, ефективним рішенням для більшості проблемних проблем, але може значно збільшити споживання пам'яті, оскільки весь буфер виділяється навіть для невеликих натискань .

Така ж помилка з Bitbucket. Виправлено

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

Трюк http.postBuffer не працював для мене. Однак:

Для інших, хто відчуває цю проблему, це може бути проблема з GnuTLS. Якщо ви встановите режим багатослідової роботи, ви можете бачити, що основна помилка виглядає щось уздовж рядків коду нижче.

На жаль, моє єдине рішення поки що - використовувати 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

Вказівки. Для зміни 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

Виходячи з цієї відповіді , я спробував наступне (з URL-адресою https):

1. початкове клонування РЕПО:

git clone --depth 25 url-here

2. Вибір здійснює збільшення в два рази за глибину спроби:

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

Отже, git want's to post 5 MB, тоді я зробив буфер публікацій 6 MB, і він працює

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 repo, розміщеного на екземплярі AWS EC2, керованого еластичною підкладкою. Само клонування також було зроблено на екземплярі 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
• використовуючи страйк для трасування git clone
• розглядаючи оновлення клієнта git

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

ОНОВЛЕННЯ

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

Співвідношення між git clone помилками і "зливом з'єднання" для нас дивне і не очевидно. Можливо, зміна часу очікування злиття з'єднання спричинило деякі внутрішні зміни в конфігурації ELB, які вирішили проблему із передчасним закриттям з'єднання.

Це пов’язане питання на форумі AWS (відповіді поки немає): https://forums.aws.amazon.com/thread.jspa?threadID=258572

У мене була схожа проблема, але з роботою з бамбука. Бамбукові не вдалося зробити локальний клон (локальний, але над SSH-проксі) кешованого сховища, я видалив кеш і після цього він працював, але щоразу, коли він намагається клонувати з локального кешу, виникає збій. Схоже, проблема з бамбуковою версією проксі SSH не git сама по собі.

У мене така ж помилка під час використання BitBucket. Що я зробив, це видалити https з URL-адреси мого репортажу та встановити URL-адресу за допомогою HTTP.

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

ВИРІШЕНО Налаштуванням маршрутизатора WIFI:

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

Швидкість завантаження Git дуже повільна 15 кбіт.

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

Рішення: 1. Змінено налаштування на Dynamic IP, перезавантажте маршрутизатор wifi. 2. Від входу в веб-браузер до порталу постачальників послуг Інтернету (не налаштовуйте PPPoE, автоматично входите через маршрутизатор wifi).

Після зміни Git швидкість завантаження становить 1,7 Мбіт.

Це вирішило мою проблему:

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

Наведені вище трюки не допомогли мені, оскільки репо було більше, ніж максимальний розмір натискань, дозволений у Github. Що вдалося зробити - це рекомендація від https://github.com/git-lfs/git-lfs/isissue/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 (Системі захисту від вторгнення), припинивши з'єднання після передачі певної кількості даних.

Для спільної пропускної здатності спробуйте клонуватись, коли завантаження менше. Інакше спробуйте з високою швидкістю з'єднання. Якщо все ще не працює, будь ласка, скористайтеся командою нижче,

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

Потім включіть наступне: * machine github.com

ім'я користувача для входу

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

машина api.github.com

ім'я користувача для входу

пароль SECRET *

Ви можете включити туди свій необроблений пароль, але з метою безпеки сгенеруйте тут маркер 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, це не є гарною відповіддю на це питання, але принаймні це працює для мене