Git klonlama sırasında uzak uç beklenmedik bir şekilde kapatıldı

Benim gitistemci defalarca süredir depo klonlamak denedikten sonra aşağıdaki hata ile başarısız olur.

Burada sorun ne olabilir?

Not: SSH anahtarımı GIT barındırma sağlayıcısına kaydettirdim

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

Hızlı çözüm:

Bu tür bir hata ile, genellikle postBufferboyutu şu şekilde yükselterek işe başlarım :

git config --global http.postBuffer 524288000

(aşağıdaki bazı yorumlar değerin iki katına çıkarılması gerektiğini bildirmektedir):

git config --global http.postBuffer 1048576000

Daha fazla bilgi:

Gönderen git configadam sayfasında , http.postBufferhakkındadır:

Verileri uzak sisteme POST yaparken akıllı HTTP aktarımları tarafından kullanılan arabellek bayt cinsinden maksimum boyut.
Bu arabellek boyutundan daha büyük istekler için, HTTP / 1.1 ve Transfer-Encoding: chunkedyerel olarak büyük bir paket dosyası oluşturmaktan kaçınmak için kullanılır. Varsayılan 1 MiB'dir ve çoğu istek için yeterlidir.

Klon için bile, bunun bir etkisi olabilir ve bu durumda OP Joe şunları bildirir:

[klon] şimdi iyi çalışıyor

Not: sunucu tarafında bir şeyler ters giderse ve sunucu Git 2.5+ (Q2 2015) kullanıyorsa, hata mesajı daha açık olabilir.
Bkz. " Git klonlama: uzak uç beklenmedik bir şekilde kapatıldı, değişmeye çalıştı, postBufferancak hala başarısız oldu ".

Kulai ( yorumlarda ) bu Atlassian Sorun Giderme Git sayfasına dikkat çekiyor :

Error code 56bir kıvrılma alma hatasını gösterir, CURLE_RECV_ERRORbu da klonlama işlemi sırasında verilerin alınmasını engelleyen bir sorun olduğu anlamına gelir.
Genellikle buna, tüm veriler aktarılmadan önce bağlantıyı kesen bir ağ ayarı, güvenlik duvarı, VPN istemcisi veya virüsten koruma neden olur.

Ayrıca, hata ayıklama işlemine yardımcı olmak için aşağıdaki ortam değişkeninden bahseder.

# 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 (Şubat 2020) ile bu http.postBuffer"çözüm" hakkında daha fazlasını biliyorsunuz .

Bkz. Taahhüt 7a2dc95 , taahhüt 1b13e90 (22 Ocak 2020), brian m. carlson ( bk2204) .
^{(Tarafından Birleştirilmiş - Junio C Hamano gitster- içinde 53a8329 taahhüt 2020 30 Oca)}
( Git Mail listesi tartışması )

docs: http.postBuffer değerini artırdığınızda bahsedin

^{İmzalayan: brian m. carlson}

Çok çeşitli durumlarda kullanıcılar kendilerini HTTP push sorunlarıyla bulurlar.

Çoğu zaman bu sorunlar antivirüs yazılımı, filtreleme proxy'leri veya diğer ortadaki adam durumlarından kaynaklanır; diğer zamanlarda, ağın basit güvenilmezliğinden kaynaklanırlar.

Ancak, çevrimiçi bulunan HTTP push sorunlarına ortak bir çözüm http.postBuffer'ı artırmaktır.

Bu, yukarıda belirtilen durumların hiçbiri için işe yaramaz ve yalnızca küçük, çok kısıtlı sayıda durumda yararlıdır: temelde, bağlantı HTTP / 1.1'i düzgün bir şekilde desteklemediğinde.

Bu değeri yükseltirken uygun olduğunu ve gerçekte ne yaptığını belgeleyin ve orada etkili olmadığı için insanları itme problemleri için genel bir çözüm olarak kullanmalarını önleyin.

Şimdilik belgeler git config http.postBufferşunları içeriyor:

http.postBuffer

Verileri uzak sisteme POST yaparken akıllı HTTP aktarımları tarafından kullanılan arabellek bayt cinsinden maksimum boyut.
Bu arabellek boyutundan daha büyük istekler için, yerel olarak büyük bir paket dosyası oluşturmaktan kaçınmak için HTTP / 1.1 ve Transfer-Encoding: chunked kullanılır.
Varsayılan, çoğu istek için yeterli olan 1 MiB'dir.

Bu sınırı yükseltmenin yalnızca yığın aktarım kodlamasını devre dışı bırakmak için etkili olduğunu ve bu nedenle yalnızca uzak sunucunun veya proxy'nin yalnızca HTTP / 1.0'ı desteklediği veya HTTP standardıyla uyumlu olmadığı durumlarda kullanılması gerektiğini unutmayın.
Bunu yükseltmek, genel olarak, çoğu itme sorunu için etkili bir çözüm değildir, ancak tüm tamponlar küçük itmeler için bile tahsis edildiğinden bellek tüketimini önemli ölçüde artırabilir .

Bitbucket ile aynı hata. Tarafından düzeltildi

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

Http.postBuffer hile yaptığı değil benim için çalışmaktadır. Ancak:

Bu sorunu yaşayan diğerleri için, bu GnuTLS ile ilgili bir sorun olabilir. Ayrıntılı modu ayarlarsanız, alttaki hatanın aşağıdaki kod satırlarında bir şey gördüğünü görebilirsiniz.

Ne yazık ki, şimdiye kadarki tek çözümüm SSH kullanmak.

Git'i GnuTLS yerine OpenSSL ile derlemek için başka bir yere gönderilen bir çözüm gördüm . Burada sorun için aktif bir hata raporu var .

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 .: Değişiyor http.postBuffer , git_lab için Nginx yapılandırma dosyasının, client_max_body_size değerini ayarlayarak istemci için daha büyük gövde boyutlarını kabul edecek şekilde ayarlanmasını gerektirebilir.

Bununla birlikte, Gitlab makinesine veya ağındaki bir makineye erişiminiz varsa ve bundan yararlanarak bir geçici çözüm vardırgit bundle .

1. kaynak makinedeki git deponuza git
2. Çalıştırmak git bundle create my-repo.bundle --all
3. my-repo.bundle dosyasını hedef makineye aktarın (örn. rsync ile)
4. hedef makinede çalıştırın git clone my-repo.bundle
5. git remote set-url origin "path/to/your/repo.git"
6. git push

Herşey gönlünce olsun!

Benim için işe yarayan tek şey , repoyu SSH bağlantısı yerine HTTPS bağlantısını kullanarak klonlamaktı .

Https kullanıyorsanız ve hatayı alıyorsanız.

Http yerine https kullandım ve sorunumu çözdü

git config --global https.postBuffer 524288000

Bu cevaba dayanarak, (https url ile) aşağıdakileri denedim:

1. Repo'nun ilk klonlanması:

git clone --depth 25 url-here

2. getirme, her deneme derinliği için iki kat artarak taahhüt eder:

git fetch --depth 50

git fetch --depth 100

git fetch --depth 200

...ve bunun gibi

3. sonunda (yeterli olduğunu düşündüğümde) koşuyorum git fetch --unshallow- ve bitti.

Süreç çok daha fazla zaman alıyor, ancak benim durumumda http.postBuffervecore.compression yardımcı olmadı.

UDP : Ben yoluyla getirilirken öğrendim ssh ile yapılır (yanlışlıkla keşfedilen) Herhangi Repo boyutu, çalışır git clone <ssh url>ssh anahtarları oluşturduk verilen. Repo getirildikten sonra, uzak adresi kullanarakgit remote set-url <https url to repo>

Aşağıdaki komutu kullandıktan sonra çözüm var:

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

Aynı sorunu aldım, deneme yanılma yöntemiyle düzelttim. Core.compression değerini çalışana kadar değiştirdim.

3 denemeden sonra "git config --global core.compression 1" ile başladım

"git config --global core.compression 4" benim için çalıştı.

Bu internet bağlantısı sorunu nedeniyle, aynı sorunla karşı karşıya. Kullanarak kod sığ bir kopyasını yaptım

git clone --depth 1 //FORKLOCATION

Daha sonra kullanarak klonun unhallowed

git fetch --unshallow

içinde /etc/resolv.confDosyanın sonuna satırı ekleyin

options single-request

Ben 219 MB'lık bir çözüm getirmek istedim, ama hiç şansım yoktu

git config --global http.postBuffer 524288000

Ve yine de 525 MB yazı tamponuna sahip olmanın anlamı nedir? aptalca. Bu yüzden aşağıdaki git hatasına baktım:

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 git 5 ​​MB yayınlamak istiyor, sonra 6 MB yazı arabelleğini yaptım ve işe yarıyor

git config --global http.postBuffer 6291456

Ben de aynı sorunu vardı ve kötü bir internet bağlantısı ile ilgili, bu yüzden bazı git configs ile denedikten sonra, ben sadece ağ bağlantısı kesildi ve tekrar bağlandı ve çalışıyor !.

Bağlantının kesilmesinden sonra (veya bu durumu tetikleyen eylemden sonra) git sıkışmış gibi görünüyor.

Umarım burada birileri için bir yardım olabilir.

En iyi,

Ben de aynı sorunu yaşadım. Bu sorunun nedeni Kurtis'in GNUTLS hakkındaki açıklamaları.

Aynı nedeniniz varsa ve sisteminiz Ubuntu ise, git'in en son sürümünü yükleyerek bu sorunu çözebilirsiniz ppa:git-core/ppa. Komutlar aşağıdaki gibidir.

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

Elastik beanstalk tarafından yönetilen AWS EC2 örneğinde barındırılan uzak git repo'dan veri (HTTP aracılığıyla) klonlarken bu sorunla karşı karşıya kaldım. Klonlamanın kendisi de AWS EC2 örneğinde yapıldı.

Yukarıda belirtilen tüm çözümleri ve bunların kombinasyonlarını denedim:

• ayar git http.postBuffer
• ayarhttp.maxrequestbuffer
• git sıkıştırmayı kapatma ve "sığ" git cloneve ardından git fetch --unshallow- ölümcül görünme: erken EOF ölümcül: dizin paketi başarısız
• çarpıcı GIT bellek ayarları - packedGitLimit ve diğerleri, buraya bakın: ölümcül: erken EOF ölümcül: dizin paketi başarısız oldu
• çarpıcı nginx yapılandırması - client_max_body_sizehem büyük değere hem de 0'a (sınırsız) ayarlama; ayarproxy_request_buffering off;
• options single-request/etc/resolv.conf içinde ayar
• kısıcı git istemci verimi damlama ile
• izleme için şerit kullanma git clone
• git istemcisinin güncellenmesi dikkate alınarak

Tüm bunlardan sonra, bağlantıyı kesen Elastik Yük Dengeleyici (ELB) ile ilgili olana kadar aynı sorunla tekrar tekrar karşılaşıyordum . ECB örneğine (bir tane git repo barındıran) doğrudan ELB'den geçtikten sonra nihayet git repo'yu klonlamayı başardım! Hala ELB (zaman aşımı) parametrelerinin bundan sorumlu olduğundan emin değilim, bu yüzden hala biraz araştırma yapmak zorundayım.

GÜNCELLEME

Zaman aşımını 20 saniyeden 300 saniyeye yükselterek AWS Elastik Yük Dengeleyici için Bağlantı Boşaltma politikasının değiştirilmesi bu sorunu bizim için çözdü.

git cloneHatalar ve "bağlantı boşaltma" arasındaki ilişki gariptir ve bizim için açık değildir. Bağlantı boşaltma zaman aşımı değişikliği, ELB yapılandırmasında erken bağlantı kapanmasıyla ilgili sorunu gideren bazı dahili değişikliklere neden olabilir.

Bu, AWS forumundaki ilgili soru (henüz yanıt yok): https://forums.aws.amazon.com/thread.jspa?threadID=258572

Benzer bir sorunum vardı, ama bambu işi ile. Bambu, önbelleğe alınmış bir deponun yerel bir klonunu (yerel ancak bir SSH proxy'si üzerinden) yapmıyordu, önbelleği sildim ve bundan sonra çalıştı, ancak yerel önbellekten klonlamaya çalıştığında herhangi bir hata var. Bambu'nun SSH proxy'sinin sürümünde gitmiş değil bir sorun gibi görünüyor.

BitBucket kullanırken aynı hata var. Yaptığım şey, depomun URL'sinden https'yi kaldırmak ve URL'yi kullanarak ayarlamaktı HTTP.

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

WIFI Router Ayarıyla ÇÖZÜLDÜ:

Ben ayarları PPPoE (wifi yönlendirici tarafından otomatik giriş) ile wifi olduğumda aynı sorunu var.

Git indirme hızı çok yavaş 15kb.

packet_write_wait: 17.121.133.16 bağlantı noktası 22'ye bağlantı: Kesik boru ölümcül: Uzak uç beklenmedik şekilde ölümcül oldu: erken EOF ölümcül: dizin paketi başarısız oldu

Çözüm: 1. Ayarı Dinamik IP olarak değiştirdi, wifi yönlendiriciyi yeniden başlatın. 2. İnternet tarayıcısı girişinden Internet servis sağlayıcı portalına (PPPoE, wifi yönlendiriciden otomatik giriş yapılandırmayın).

Git değiştirildikten sonra indirme hızı 1.7MiB'dir.

Bu benim sorunumu çözdü:

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

Repo, github'da izin verilen maksimum itme boyutundan daha büyük olduğu için yukarıdaki hileler bana yardımcı olmadı. Ne işe yaradı https://github.com/git-lfs/git-lfs/issues/3758 bir kerede biraz itmeyi öneren bir öneriydi:

Şubenizin uzun bir geçmişi varsa, böyle bir şeyle aynı anda daha az sayıda taahhüt (örneğin, 2000) göndermeyi deneyebilirsiniz:

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

Bu, her seferinde 2000 nesnelerini iterek ustanın tarihi boyunca ilerleyecektir. (Elbette, isterseniz her iki yerde de farklı bir dal kullanabilirsiniz.) Bu bittiğinde, ustayı son kez itebilmelisiniz ve işler güncel olmalıdır. 2000 çok fazlaysa ve sorunu tekrar vurursanız, sayıyı daha küçük olacak şekilde ayarlayabilirsiniz.

Bu çözümlerden bazılarını denemek için birkaç saat harcadık, ancak sonunda bunu belirli bir miktarda veri aktarıldıktan sonra bağlantıyı kesen bir kurumsal IPS'ye (Enstrüman Koruma Sistemi) kadar takip etti.

Paylaşılan bant genişliği için, yük az olduğunda klonlamaya çalışın. Aksi takdirde, yüksek hızlı bir bağlantı kullanmayı deneyin. Hala çalışmıyorsa, lütfen aşağıdaki komutu kullanın,

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

Ve tekrar klonlamaya çalışın. Bu ayarları kullanılabilir bellek boyutunuza göre değiştirmeniz gerekebilir.

Bir sunucu problemi kadar basit olabilir. GitHub kullanıyorsanız, https://twitter.com/githubstatus adresini kontrol edin . Bunu ilk kez gördüm ve GitHub'ın bir yalpalama olduğunu keşfettim . Birkaç dakika sonra tekrar iyi çalıştı.

Bu benim için çalıştı, standart ad sunucusu belirtilmediğinden Googles ad sunucusu ayarlandı, ardından ağ yeniden başlatıldı:

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

Kubuntu'da git kullanarak bu sorunla karşılaştım. Ayrıca ağ oluşturmadaki genel dengesizliği fark ettim ve bir çözüm buldum .

/etc/resolv.conf dosyasında satırı dosyanın sonuna ekleyin

seçenekler tek istek

Bu sabit her alan adı çözümlemesi gecikmeden önce ve git bundan sonra bir cazibe gibi çalışmaya başladı.

Benim sorunum .netrc dosyası ile olmak bulundu, eğer öyleyse sizin için de o zaman aşağıdakileri yapabilirsiniz:

.Netrc dosyanızı açın ve github kimlik bilgilerini içerecek şekilde düzenleyin. Tür nano ~/netrcveyagedit ~/netrc

Sonra aşağıdakileri ekleyin: * machine github.com

Kullanıcı adını gir

şifre GİZLİ

makine api.github.com

Kullanıcı adını gir

şifre GİZLİ *

Ham şifrenizi buraya ekleyebilirsiniz, ancak güvenlik nedeniyle, burada bir kimlik doğrulama kodu oluşturun github belirteci ve parolanızın yerine yapıştırın.

Umarım bu birine yardımcı olur

Taahhüt edilenlerin boyutu itiliyor olabilir. Taahhütlerin sayısını aşağıdaki adımlarla dağıtın:

git log -5

Son 5 taahhüdü görün ve hangilerinin uzaktan kumandaya itilmediğini bileceksiniz. Bir taahhüt kimliği seçin ve tüm taahhütleri bu kimliğe kadar itin:

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

NOT: Sadece en büyük boyuta sahip olan taahhüdümü kontrol ettim; ilk önce o zamana kadar itti. Hile çalıştı. !!

OS X El Capitan Mac'imden git push yapıyordum. Aynı hatayı alıyordum, düzeltmek için her şeyi denedim, google / stackoverflow'da bulduğum şey. Sürümü ile ilgili olarak, 2.7.4 olan github oldukça son sürümünü kullanıyorum. Yerel sistemimde bir proje oluşturdum ve bunun github hesabımda herkese açık olmasını istedim. Proje boyutu 8 MB civarında değildi. 1.5MB civarında bazı dosyaları iterken, düzgün bir şekilde ittiğini fark ettim, ancak büyük boyutta benim için başarısız oldu, aynı hatayla,

Sahip olduğum tek seçenek MB yığınındaki değişiklikleri zorlamaktı. Şimdi tüm değişiklikleri ittim. Bu çözüm için düzeltme elde edene kadar bu benim için geçici bir çözümdür.

Böylece değişikliği birden fazla işlemde zorlamayı da deneyebilirsiniz. Veya birden fazla klasörünüz varsa, her bir klasördeki değişiklikleri itebilirsiniz (klasör boyutu büyük değilse).

Umarım bu proje üzerinde sürekli çalışmanıza yardımcı olacaktır.

Aynı sorunla karşı karşıya kalırsanız, başka bir dalla birleşmeye ve onlardan bir çekmeye çalışın. Benim için de geçerli.

kullanmak sshyerine httpbu soruya iyi bir cevap değil, ama en azından benim için çalışıyor