Ujung remote menutup secara tak terduga saat git mengkloning

gitKlien saya berulang kali gagal dengan kesalahan berikut setelah mencoba mengkloning repositori untuk beberapa waktu.

Apa yang bisa menjadi masalah di sini?

Catatan: Saya telah mendaftarkan kunci SSH saya ke penyedia hosting GIT

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

Solusi cepat:

Dengan kesalahan semacam ini, saya biasanya memulai dengan menaikkan postBufferukuran dengan:

git config --global http.postBuffer 524288000

(beberapa komentar di bawah melaporkan harus menggandakan nilai):

git config --global http.postBuffer 1048576000

Informasi lebih lanjut:

Dari git confighalaman manual , http.postBufferadalah tentang:

Ukuran maksimum dalam byte buffer yang digunakan oleh HTTP pintar mengangkut saat POSTing data ke sistem jarak jauh.
Untuk permintaan yang lebih besar dari ukuran buffer ini, HTTP / 1.1 dan Transfer-Encoding: chunkeddigunakan untuk menghindari pembuatan file paket besar secara lokal. Default adalah 1 MiB, yang cukup untuk sebagian besar permintaan.

Bahkan untuk klon, itu dapat memiliki efek, dan dalam hal ini, OP Joe melaporkan:

[klon] berfungsi dengan baik sekarang

Catatan: jika ada masalah di sisi server, dan jika server menggunakan Git 2.5+ (Q2 2015), pesan kesalahan mungkin lebih eksplisit.
Lihat " Kloning Git: ujung jarak jauh menutup secara tak terduga, mencoba mengubah postBuffertetapi masih gagal ".

Kulai ( dalam komentar ) menunjukkan halaman Git Pemecahan Masalah Atlassian ini , yang menambahkan:

Error code 56menunjukkan curl menerima kesalahan CURLE_RECV_ERRORyang berarti ada beberapa masalah yang mencegah data diterima selama proses kloning.
Biasanya ini disebabkan oleh pengaturan jaringan, firewall, klien VPN, atau anti-virus yang memutuskan koneksi sebelum semua data ditransfer.

Ini juga menyebutkan variabel lingkungan berikut, untuk membantu proses debugging.

# 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

Dengan Git 2.25.1 (Februari 2020), Anda tahu lebih banyak tentang http.postBuffer"solusi" ini.

Lihat komit 7a2dc95 , komit 1b13e90 (22 Jan 2020) oleh brian m. carlson ( bk2204) .
^{(Digabung oleh Junio ​​C Hamano - gitster- dalam komit 53a8329 , 30 Jan 2020)}
( Diskusi Milis Git )

docs: sebutkan ketika meningkatkan http.postBuffer berharga

^{Ditandatangani oleh: brian m. carlson}

Pengguna dalam berbagai situasi menemukan diri mereka dengan masalah push HTTP.

Seringkali masalah ini disebabkan oleh perangkat lunak antivirus, penyaringan proxy, atau situasi manusia-di-tengah lainnya; di lain waktu, mereka disebabkan oleh jaringan yang tidak dapat diandalkan.

Namun, solusi umum untuk masalah push HTTP yang ditemukan online adalah dengan meningkatkan http.postBuffer.

Ini tidak bekerja untuk situasi yang disebutkan di atas dan hanya berguna dalam sejumlah kecil, sangat terbatas kasus: pada dasarnya, ketika koneksi tidak mendukung HTTP / 1.1 dengan benar.

Dokumentasikan ketika menaikkan nilai ini sesuai dan apa yang sebenarnya dilakukannya, dan jangan gunakan orang sebagai solusi umum untuk masalah push, karena tidak efektif di sana.

Jadi dokumentasi untuk git config http.postBuffersaat ini meliputi:

http.postBuffer

Ukuran maksimum dalam byte buffer yang digunakan oleh HTTP pintar mengangkut saat POSTing data ke sistem jarak jauh.
Untuk permintaan yang lebih besar dari ukuran buffer ini, HTTP / 1.1 dan Transfer-Encoding: chunked digunakan untuk menghindari pembuatan file paket besar secara lokal.
Default adalah 1 MiB, yang cukup untuk sebagian besar permintaan.

Perhatikan bahwa menaikkan batas ini hanya efektif untuk menonaktifkan pengkodean transfer chunked dan oleh karena itu harus digunakan hanya jika server jarak jauh atau proxy hanya mendukung HTTP / 1.0 atau tidak sesuai dengan standar HTTP.
Meningkatkan ini bukan, secara umum, solusi efektif untuk sebagian besar masalah dorong, tetapi dapat meningkatkan konsumsi memori secara signifikan karena seluruh buffer dialokasikan bahkan untuk dorongan kecil .

Kesalahan yang sama dengan Bitbucket. Diperbaiki oleh

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

Trik http.postBuffer tidak berfungsi untuk saya. Namun:

Bagi orang lain yang mengalami masalah ini, mungkin ada masalah dengan GnuTLS. Jika Anda mengatur mode Verbose, Anda mungkin melihat kesalahan yang mendasari melihat sesuatu di sepanjang baris kode di bawah ini.

Sayangnya, satu-satunya solusi saya sejauh ini adalah menggunakan SSH.

Saya telah melihat solusi yang diposting di tempat lain untuk mengkompilasi Git dengan OpenSSL bukan GnuTLS. Ada laporan bug aktif untuk masalah ini di sini .

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 .: Mengubah http.postBuffermungkin juga perlu mengatur file konfigurasi Nginx agar gitlab menerima ukuran tubuh yang lebih besar untuk klien, dengan menyetel nilai client_max_body_size.

Namun, ada solusi jika Anda memiliki akses ke mesin Gitlab atau ke mesin di jaringannya, dan itu adalah dengan memanfaatkan git bundle.

1. buka repositori git Anda di mesin sumber
2. Lari git bundle create my-repo.bundle --all
3. mentransfer (mis., dengan rsync) file my-repo.bundle ke mesin tujuan
4. di mesin tujuan, jalankan git clone my-repo.bundle
5. git remote set-url origin "path/to/your/repo.git"
6. git push

Semua yang terbaik!

Satu-satunya hal yang berhasil bagi saya adalah mengkloning repo menggunakan tautan HTTPS alih-alih tautan SSH .

Jika Anda menggunakan https dan Anda mendapatkan kesalahan.

Saya menggunakan https alih-alih http dan itu memecahkan masalah saya

git config --global https.postBuffer 524288000

Berdasarkan jawaban ini , saya mencoba mengikuti (dengan https url):

1. kloning awal repo:

git clone --depth 25 url-here

2. ambil komitmen dengan peningkatan dua kali per kedalaman coba:

git fetch --depth 50

git fetch --depth 100

git fetch --depth 200

...dan seterusnya

3. akhirnya (ketika saya pikir sudah cukup diambil) saya lari git fetch --unshallow- dan itu selesai.

Prosesnya jelas membutuhkan lebih banyak waktu, tetapi dalam pengaturan kasus saya http.postBufferdan core.compressiontidak membantu.

UPD : Saya menemukan bahwa mengambil via ssh berfungsi untuk ukuran repo (ditemukan secara tidak sengaja), dilakukan dengan git clone <ssh url>, mengingat Anda telah membuat kunci ssh. Setelah repo diambil, saya mengubah alamat jarak jauh menggunakangit remote set-url <https url to repo>

Saya mendapat solusi setelah menggunakan perintah di bawah ini:

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

Saya mendapat masalah yang sama, saya memperbaikinya dengan metode coba-coba. Saya mengubah nilai core.compression hingga berfungsi.

Saya mulai dengan "git config --global core.compression 1" setelah 3 upaya

"git config --global core.compression 4" bekerja untuk saya.

Ini karena masalah konektivitas internet, saya menghadapi masalah yang sama. Saya melakukan salinan kode dangkal menggunakan

git clone --depth 1 //FORKLOCATION

Kemudian unallalling clone menggunakan

git fetch --unshallow

di /etc/resolv.conftambahkan baris ke akhir file

options single-request

Yah, saya ingin mendorong solusi 219 MB, tetapi saya tidak beruntung

git config --global http.postBuffer 524288000

Dan apa gunanya memiliki buffer post 525 MB? ini konyol. Jadi saya melihat kesalahan git di bawah ini:

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

Jadi git mau postingan 5 MB, lalu saya buat post buffer 6 MB, dan berhasil

git config --global http.postBuffer 6291456

Saya memiliki masalah yang sama dan itu terkait dengan koneksi internet yang buruk, jadi setelah mencoba dengan beberapa konfigurasi git, saya baru saja terputus dari jaringan saya dan terhubung lagi dan berfungsi !.

Tampaknya setelah koneksi terputus (atau aksi yang memicu situasi ini), git macet.

Saya berharap ini bisa menjadi bantuan bagi seseorang yang lebih di sini.

Terbaik,

Saya juga memiliki masalah yang sama. Alasan untuk masalah ini adalah sebagai deskripsi Kurtis tentang GNUTLS.

Jika Anda memiliki alasan yang sama dan sistem Anda adalah Ubuntu, Anda dapat menyelesaikan masalah ini dengan menginstal git versi terbaru dari ppa:git-core/ppa . Perintahnya adalah seperti di bawah ini.

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

Saya menghadapi masalah ini ketika mengkloning data (melalui HTTP) dari repo git jarak jauh yang di-host pada AWS EC2 yang dikelola oleh beanstalk elastis. Kloning itu sendiri juga dilakukan pada contoh AWS EC2.

Saya mencoba semua solusi yang disebutkan di atas dan kombinasinya:

• pengaturan git http.postBuffer
• pengaturanhttp.maxrequestbuffer
• mematikan kompresi git dan mencoba "dangkal" git clonedan kemudian git fetch --unshallow- lihat fatal: EOF awal fatal: paket-indeks gagal
• menyetel pengaturan memori GIT - packedGitLimit dkk, lihat di sini: fatal: EOF awal fatal: paket-indeks gagal
• tunning konfigurasi nginx - pengaturan client_max_body_size ke nilai besar dan 0 (tidak terbatas); pengaturanproxy_request_buffering off;
• pengaturan options single-request di /etc/resolv.conf
• melambatkan throughput git client dengan tetesan
• menggunakan strace untuk melacak git clone
• mempertimbangkan pembaruan git client

Setelah semua ini, saya masih menghadapi masalah yang sama berulang-ulang, sampai saya menemukan bahwa masalah ada di Elastic Load Balancer (ELB) memotong koneksi . Setelah mengakses instance EC2 (hosting git repo) secara langsung dan bukannya melalui ELB, saya akhirnya berhasil mengkloning git repo! Saya masih tidak yakin yang mana dari ELB (batas waktu) parameter yang bertanggung jawab untuk ini, jadi saya masih harus melakukan riset.

MEMPERBARUI

Tampaknya mengubah kebijakan Pengurasan Koneksi untuk AWS Elastic Load Balancer dengan menaikkan batas waktu dari 20 detik menjadi 300 detik menyelesaikan masalah ini bagi kami.

Hubungan antara git clonekesalahan dan "koneksi koneksi" aneh dan tidak jelas bagi kami. Mungkin karena perubahan batas waktu pengeringan koneksi menyebabkan beberapa perubahan internal dalam konfigurasi ELB yang memperbaiki masalah dengan penutupan koneksi prematur.

Ini adalah pertanyaan terkait di forum AWS (belum ada jawaban): https://forums.aws.amazon.com/thread.jspa?threadID=258572

Saya memiliki masalah yang sama, tetapi dengan pekerjaan bambu. Bamboo gagal melakukan klon lokal (lokal tetapi melalui proxy SSH) dari repositori yang di-cache, saya menghapus cache dan setelah itu berhasil, tetapi setiap kali ia mencoba untuk mengkloning dari cache lokal ada kegagalan. Sepertinya masalah dengan versi bambu dari proxy SSH tidak git per se.

Saya memiliki kesalahan yang sama saat menggunakan BitBucket. Apa yang saya lakukan adalah menghapus https dari URL repo saya dan mengatur URL menggunakan HTTP.

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

ASK DENGAN Pengaturan Router WIFI:

Saya mendapat masalah yang sama ketika saya berada di wifi dengan Pengaturan PPPoE (login otomatis oleh router wifi).

Kecepatan unduh Git sangat lambat 15kb.

package_write_wait: Sambungan ke port 17.121.133.16 22: Pipa rusak fatal: Ujung jarak jauh mematikan fatal: awal EOF fatal: paket-indeks gagal

Solusi: 1. Mengubah pengaturan ke Dynamic IP, me-reboot router wifi. 2. Dari login browser web ke portal penyedia layanan Internet (jangan mengkonfigurasi PPPoE, login otomatis dari router wifi).

Setelah mengubah kecepatan unduhan Git adalah 1.7MiB.

Ini menyelesaikan masalah saya:

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

Trik di atas tidak membantu saya, karena repo lebih besar dari ukuran dorong maks yang diperbolehkan di github. Apa yang berhasil adalah rekomendasi dari https://github.com/git-lfs/git-lfs/issues/3758 yang menyarankan untuk sedikit mendorong sekaligus:

Jika cabang Anda memiliki sejarah panjang, Anda dapat mencoba mendorong jumlah komit yang lebih sedikit pada satu waktu (katakanlah, 2000) dengan sesuatu seperti ini:

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

Itu akan berjalan melalui sejarah master, mendorong benda 2000 sekaligus. (Tentu saja, Anda dapat mengganti cabang yang berbeda di kedua tempat jika Anda mau.) Ketika itu selesai, Anda harus dapat mendorong master untuk yang terakhir kalinya, dan segala sesuatunya harus terkini. Jika 2000 terlalu banyak dan Anda mendapatkan masalah lagi, Anda dapat menyesuaikan jumlahnya sehingga lebih kecil.

Membuang waktu beberapa jam untuk mencoba beberapa solusi ini tetapi akhirnya melacak ini ke IPS perusahaan (Instrusion Protection System) yang menjatuhkan koneksi setelah sejumlah data ditransfer.

Untuk bandwidth bersama, cobalah untuk mengkloning ketika memuat lebih sedikit. Jika tidak, coba dengan koneksi kecepatan tinggi. Jika masih tidak berfungsi, silakan gunakan perintah di bawah ini,

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

Dan cobalah untuk mengkloning lagi. Anda mungkin perlu mengubah pengaturan itu sesuai dengan ukuran memori yang tersedia.

Ini mungkin sesederhana masalah server. Jika menggunakan GitHub, periksa https://twitter.com/githubstatus . Saya melihat ini untuk pertama kalinya sekarang dan menemukan GitHub sedang goyah . Beberapa menit kemudian itu bekerja dengan baik.

Ini bekerja untuk saya, menyiapkan server nama Google karena server nama standar tidak ditentukan, diikuti dengan memulai ulang jaringan:

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

Saya menghadapi masalah ini dengan menggunakan git di Kubuntu. Saya juga memperhatikan ketidakstabilan keseluruhan dalam jaringan dan menemukan solusi .

di /etc/resolv.conf tambahkan baris ke akhir file

opsi permintaan tunggal

Ini memperbaiki penundaan sebelum setiap resolusi nama domain dan git mulai bekerja seperti pesona setelah ini.

Saya menemukan masalah saya dengan file .netrc, jika demikian untuk Anda juga maka Anda dapat melakukan hal berikut:

Buka file .netrc Anda dan edit untuk memasukkan kredensial github. Ketik nano ~/netrcataugedit ~/netrc

Kemudian sertakan yang berikut: * machine github.com

nama pengguna login

kata sandi RAHASIA

mesin api.github.com

nama pengguna login

kata sandi RAHASIA *

Anda dapat memasukkan kata sandi mentah Anda di sana tetapi untuk tujuan keamanan, buat token auth di sini github token dan tempel di tempat kata sandi Anda.

Semoga ini bisa membantu seseorang

Mungkin karena ukuran komit yang didorong. Rincian jumlah komit oleh langkah-langkah berikut:

git log -5

Lihat 5 komit terakhir dan Anda akan tahu mana yang tidak didorong ke jarak jauh. Pilih id komit dan dorong semua komit ke id itu:

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

CATATAN: Saya baru saja memeriksa komit saya yang bisa memiliki ukuran terbesar; pertama didorong ke atas sampai saat itu. Triknya berhasil. !!

Saya melakukan push git dari OS X El Capitan Mac saya. Saya mendapatkan kesalahan yang sama, saya mencoba segalanya untuk memperbaikinya, apa yang saya temukan di google / stackoverflow. Sejauh menyangkut versi saya menggunakan versi github yang cukup terbaru yaitu 2.7.4. Saya telah membuat proyek di sistem lokal saya, dan saya ingin ini dipublikasikan di akun github saya. Ukuran proyek tidak sekitar 8MB. Saya perhatikan bahwa ketika saya mendorong beberapa file berukuran sekitar 1,5MB, itu mendorong dengan benar, tetapi dengan ukuran besar gagal bagi saya, dengan kesalahan yang sama,

Satu-satunya pilihan yang saya miliki adalah untuk mendorong perubahan pada MB. Sekarang saya telah mendorong semua perubahan. Ini solusi bagi saya sampai saya mendapatkan solusi untuk perbaikan ini.

Jadi, Anda juga dapat mencoba mendorong perubahan di beberapa komit. Atau jika Anda memiliki banyak folder, Anda dapat mendorong perubahan pada setiap folder (jika ukuran folder tidak besar).

Semoga ini bisa membantu Anda untuk terus mengerjakan proyek.

Menghadapi masalah yang sama, cobalah untuk bergabung dengan cabang lain dan tarik dari mereka. Itu bekerja untuk saya sama.

gunakan sshalih-alih http, itu bukan jawaban yang baik untuk pertanyaan ini tetapi setidaknya itu berfungsi untuk saya