Kết thúc từ xa treo lên bất ngờ trong khi git nhân bản

Máy gitkhách của tôi liên tục bị lỗi với lỗi sau khi cố gắng sao chép kho lưu trữ một thời gian.

Điều gì có thể là vấn đề ở đây?

Lưu ý: Tôi đã đăng ký khóa SSH của mình với nhà cung cấp dịch vụ lưu trữ GIT

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

Giải pháp nhanh chóng:

Với loại lỗi này, tôi thường bắt đầu bằng cách tăng postBufferkích thước bằng cách:

git config --global http.postBuffer 524288000

(một số ý kiến ​​dưới đây báo cáo phải tăng gấp đôi giá trị):

git config --global http.postBuffer 1048576000

Thêm thông tin:

Từ git configtrang người đàn ông , http.postBufferlà về:

Kích thước tối đa tính bằng byte của bộ đệm được sử dụng bởi vận chuyển HTTP thông minh khi POST dữ liệu lên hệ thống từ xa.
Đối với các yêu cầu lớn hơn kích thước bộ đệm này, HTTP / 1.1 và Transfer-Encoding: chunkedđược sử dụng để tránh tạo tệp gói lớn cục bộ. Mặc định là 1 MiB, đủ cho hầu hết các yêu cầu.

Ngay cả đối với bản sao, điều đó có thể có ảnh hưởng và trong trường hợp này, OP Joe báo cáo:

[clone] hoạt động tốt bây giờ

Lưu ý: nếu có lỗi xảy ra ở phía máy chủ và nếu máy chủ sử dụng Git 2.5+ (quý 2 năm 2015), thông báo lỗi có thể rõ ràng hơn.
Xem " Nhân bản Git: đầu từ xa bị treo bất ngờ, đã thử thay đổi postBuffernhưng vẫn không thành công ".

Kulai ( trong các bình luận ) chỉ ra trang Git khắc phục sự cố Atlassian này , có thêm:

Error code 56cho thấy một curl nhận được lỗi CURLE_RECV_ERRORcó nghĩa là có một số vấn đề ngăn dữ liệu được nhận trong quá trình nhân bản.
Thông thường, điều này là do cài đặt mạng, tường lửa, máy khách VPN hoặc phần mềm chống vi-rút đang chấm dứt kết nối trước khi tất cả dữ liệu được truyền.

Nó cũng đề cập đến biến môi trường sau đây, để giúp cho quá trình gỡ lỗi.

# 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

Với Git 2.25.1 (tháng 2 năm 2020), bạn biết thêm về http.postBuffer"giải pháp" này.

Xem cam kết 7a2dc95 , cam kết 1b13e90 (ngày 22 tháng 1 năm 2020) bởi brian m. carlson ( bk2204) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết 53a8329 , ngày 30 tháng 1 năm 2020)}
( thảo luận danh sách Git Mailing )

docs: đề cập khi tăng http.postBuffer có giá trị

^{Đã ký tắt: brian m. carlson}

Người dùng trong nhiều tình huống khác nhau thấy mình gặp vấn đề về đẩy HTTP.

Thông thường, những vấn đề này là do phần mềm chống vi-rút, lọc proxy hoặc các tình huống trung gian khác; lần khác, chúng là do sự không tin cậy đơn giản của mạng.

Tuy nhiên, một giải pháp phổ biến cho các vấn đề đẩy HTTP được tìm thấy trực tuyến là tăng http.postBuffer.

Điều này hoạt động cho bất kỳ tình huống nào đã nói ở trên và chỉ hữu ích trong một số ít trường hợp bị hạn chế cao: về cơ bản, khi kết nối không hỗ trợ đúng cách HTTP / 1.1.

Tài liệu khi nâng giá trị này là phù hợp và những gì nó thực sự làm, và không khuyến khích mọi người sử dụng nó như một giải pháp chung cho các vấn đề đẩy, vì nó không hiệu quả ở đó.

Vì vậy, tài liệu cho git config http.postBufferbây giờ bao gồm:

http.postBuffer

Kích thước tối đa tính bằng byte của bộ đệm được sử dụng bởi vận chuyển HTTP thông minh khi POST dữ liệu lên hệ thống từ xa.
Đối với các yêu cầu lớn hơn kích thước bộ đệm này, HTTP / 1.1 và Mã hóa chuyển: chunked được sử dụng để tránh tạo tệp gói lớn cục bộ.
Mặc định là 1 MiB, đủ cho hầu hết các yêu cầu.

Lưu ý rằng việc tăng giới hạn này chỉ có hiệu quả trong việc vô hiệu hóa mã hóa chuyển khối và do đó chỉ nên được sử dụng khi máy chủ từ xa hoặc proxy chỉ hỗ trợ HTTP / 1.0 hoặc không tuân thủ tiêu chuẩn HTTP.
Nói chung, việc nâng cao này không phải là một giải pháp hiệu quả cho hầu hết các vấn đề đẩy, nhưng có thể làm tăng đáng kể mức tiêu thụ bộ nhớ vì toàn bộ bộ đệm được phân bổ ngay cả cho các lần đẩy nhỏ .

Lỗi tương tự với Bitbucket. Được sửa chữa bởi

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

Thủ thuật http.postBuffer không hiệu quả với tôi. Tuy nhiên:

Đối với những người khác gặp vấn đề này, nó có thể là một vấn đề với GnuTLS. Nếu bạn đặt chế độ Verbose, bạn có thể thấy lỗi cơ bản trông giống như các dòng mã bên dưới.

Thật không may, giải pháp duy nhất của tôi cho đến nay là sử dụng SSH.

Tôi đã thấy một giải pháp được đăng ở nơi khác để biên dịch Git bằng OpenSSL thay vì GnuTLS. Có một báo cáo lỗi hoạt động cho vấn đề ở đây .

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

Quan sát: Thay đổi http.postBuffercũng có thể yêu cầu thiết lập tệp cấu hình Nginx cho gitlab để chấp nhận kích thước cơ thể lớn hơn cho máy khách, bằng cách điều chỉnh giá trị của client_max_body_size.

Tuy nhiên, có một cách giải quyết nếu bạn có quyền truy cập vào máy Gitlab hoặc đến một máy trong mạng của nó và đó là bằng cách sử dụng git bundle.

1. đi đến kho git của bạn trên máy nguồn
2. chạy git bundle create my-repo.bundle --all
3. chuyển (ví dụ: với rsync) tệp my-repo.bundle sang máy đích
4. trên máy đích, chạy git clone my-repo.bundle
5. git remote set-url origin "path/to/your/repo.git"
6. git push

Tất cả là tốt nhất!

Điều duy nhất hiệu quả với tôi là sao chép repo bằng liên kết HTTPS thay vì liên kết SSH .

Nếu bạn đang sử dụng https và bạn đang gặp lỗi.

Tôi đã sử dụng https thay vì http và nó đã giải quyết vấn đề của tôi

git config --global https.postBuffer 524288000

Dựa trên câu trả lời này , tôi đã thử làm theo (với url https):

1. nhân bản ban đầu của repo:

git clone --depth 25 url-here

2. tìm nạp cam kết với tăng gấp đôi mỗi lần thử độ sâu:

git fetch --depth 50

git fetch --depth 100

git fetch --depth 200

...và như thế

3. cuối cùng (khi tôi nghĩ đủ là lấy) Tôi chạy git fetch --unshallow- và thế là xong.

Quá trình rõ ràng mất nhiều thời gian hơn, nhưng trong trường hợp của tôi http.postBuffervà core.compressionkhông giúp được gì.

CẬP NHẬT : Tôi phát hiện ra rằng việc tìm nạp thông qua ssh hoạt động với mọi kích thước repo (được phát hiện tình cờ), được thực hiện với git clone <ssh url>điều kiện bạn đã tạo các khóa ssh. Khi repo được tìm nạp, tôi thay đổi địa chỉ từ xa bằng cách sử dụnggit remote set-url <https url to repo>

Tôi đã nhận được giải pháp sau khi sử dụng lệnh dưới đây:

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

Tôi gặp vấn đề tương tự, tôi đã sửa lỗi này bằng phương pháp dùng thử và lỗi. Tôi đã thay đổi giá trị core.compression cho đến khi nó hoạt động.

Tôi đã bắt đầu với "git config --global core.compression 1" sau 3 lần thử

"Git config --global core.compression 4" đã làm việc cho tôi.

Điều này là do vấn đề kết nối internet, tôi phải đối mặt với vấn đề tương tự. Tôi đã làm một bản sao nông bằng cách sử dụng

git clone --depth 1 //FORKLOCATION

Sau đó không được sử dụng bản sao

git fetch --unshallow

trong /etc/resolv.confthêm dòng vào cuối của tập tin

options single-request

Chà, tôi muốn đẩy một giải pháp 219 MB, nhưng tôi không có may mắn với

git config --global http.postBuffer 524288000

Và điểm quan trọng của việc có bộ đệm bài 525 MB là gì? thật ngớ ngẩn. Vì vậy, tôi đã xem xét lỗi git dưới đây:

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

Vì vậy, git muốn đăng 5 MB, sau đó tôi đã tạo bộ đệm bài đăng 6 MB và nó hoạt động

git config --global http.postBuffer 6291456

Tôi có cùng một vấn đề và nó có liên quan đến kết nối internet kém, vì vậy sau khi thử với một số cấu hình git, tôi vừa ngắt kết nối với mạng của mình và kết nối lại và nó hoạt động!.

Có vẻ như sau khi mất kết nối (hoặc hành động kích hoạt tình huống này), git bị kẹt.

Tôi hy vọng rằng nó có thể là một trợ giúp cho một người nào đó nhiều hơn ở đây.

Tốt,

Tôi cũng gặp vấn đề tương tự. Lý do cho vấn đề này là những mô tả của Kurtis về GNUTLS.

Nếu bạn có cùng lý do và hệ thống của bạn là Ubuntu, bạn có thể giải quyết vấn đề này bằng cách cài đặt phiên bản git mới nhất từ ppa:git-core/ppa. Các lệnh như dưới đây.

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

Tôi đã phải đối mặt với vấn đề này khi nhân bản dữ liệu (thông qua HTTP) từ repo git từ xa được lưu trữ trên phiên bản AWS EC2 được quản lý bởi beanstalk đàn hồi. Bản sao nhân bản cũng được thực hiện trên ví dụ AWS EC2.

Tôi đã thử tất cả các giải pháp đã nói ở trên và sự kết hợp của chúng:

• thiết lập git http.postBuffer
• cài đặthttp.maxrequestbuffer
• tắt nén git và thử "nông" git clonevà sau đó git fetch --unshallow- xem fatal: EOF sớm fatal: index-pack fail
• điều chỉnh cài đặt bộ nhớ GIT - packedGitLimit et al, xem tại đây: fatal: EOF sớm fatal: index-pack fail
• điều chỉnh cấu hình nginx - cài đặt client_max_body_sizecả giá trị lớn và 0 (không giới hạn); cài đặtproxy_request_buffering off;
• cài đặt options single-requesttrong /etc/resolv.conf
• điều chỉnh thông lượng git của khách hàng với nhỏ giọt
• sử dụng strace để truy tìm git clone
• xem xét cập nhật của khách hàng git

Sau tất cả những điều này, tôi vẫn phải đối mặt với cùng một vấn đề lặp đi lặp lại, cho đến khi tôi thấy vấn đề đó nằm ở Bộ cân bằng tải đàn hồi (ELB) cắt kết nối . Sau khi truy cập trực tiếp vào phiên bản EC2 (một máy chủ lưu trữ git repo) thay vì đi qua ELB, cuối cùng tôi đã quản lý để sao chép git repo! Tôi vẫn không chắc chắn các tham số ELB (thời gian chờ) nào chịu trách nhiệm cho việc này, vì vậy tôi vẫn phải thực hiện một số nghiên cứu.

CẬP NHẬT

Có vẻ như việc thay đổi chính sách Thoát kết nối cho AWS Đàn hồi tải cân bằng bằng cách tăng thời gian chờ từ 20 giây lên 300 giây đã giải quyết vấn đề này cho chúng tôi.

Mối quan hệ giữa các git clonelỗi và "thoát kết nối" là lạ và không rõ ràng đối với chúng tôi. Có thể việc thay đổi hết thời gian chờ kết nối đã gây ra một số thay đổi bên trong cấu hình ELB đã khắc phục sự cố khi đóng kết nối sớm.

Đây là câu hỏi liên quan trên diễn đàn AWS (chưa có câu trả lời): https://forums.aws.amazon.com/thread.jspa?threadID=258572

Tôi đã có một vấn đề tương tự, nhưng với một công việc tre. Tre đã thất bại trong việc sao chép cục bộ (cục bộ nhưng qua proxy SSH) của kho lưu trữ được lưu trong bộ nhớ cache, tôi đã xóa bộ đệm và sau đó nó hoạt động, nhưng bất cứ khi nào nó cố gắng sao chép từ bộ đệm cục bộ thì đều có lỗi. Có vẻ như có vấn đề với phiên bản SSH proxy của tre không phải là git per se.

Tôi có cùng một lỗi trong khi sử dụng BitBucket. Những gì tôi đã làm là xóa https khỏi URL của repo của tôi và đặt URL bằng cách sử dụng HTTP.

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

GIẢI QUYẾT VỚI Cài đặt bộ định tuyến WIFI:

Tôi gặp vấn đề tương tự khi tôi ở trong wifi với Cài đặt PPPoE (tự động đăng nhập bằng bộ định tuyến wifi).

Tốc độ tải Git rất chậm 15kb.

pack_write_wait: Kết nối tới 17.121.133.16 cổng 22: Hỏng đường ống gây chết người: Đầu từ xa bị treo lên bất ngờ gây tử vong: EOF sớm gây tử vong: gói chỉ mục không thành công

Giải pháp: 1. Thay đổi cài đặt thành Dynamic IP, khởi động lại bộ định tuyến wifi. 2. Từ đăng nhập trình duyệt web đến cổng nhà cung cấp dịch vụ Internet (không định cấu hình PPPoE, tự động đăng nhập từ bộ định tuyến wifi).

Sau khi thay đổi tốc độ tải xuống Git là 1.7MiB.

Điều này đã giải quyết vấn đề của tôi:

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

Các thủ thuật trên không giúp tôi được gì, vì repo lớn hơn kích thước đẩy tối đa được phép tại github. Những gì đã làm là một đề xuất từ https://github.com/git-lfs/git-lfs/issues/3758 trong đó đề xuất đẩy một chút tại một thời điểm:

Nếu chi nhánh của bạn có một lịch sử lâu dài, bạn có thể thử đẩy số lượng cam kết nhỏ hơn tại một thời điểm (giả sử, 2000) bằng một cái gì đó như thế này:

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

Điều đó sẽ đi qua lịch sử của chủ nhân, đẩy các vật thể 2000 tại một thời điểm. (Tất nhiên, bạn có thể thay thế một chi nhánh khác ở cả hai nơi nếu bạn muốn.) Khi hoàn thành, bạn sẽ có thể đẩy chủ nhân một lần cuối cùng, và mọi thứ sẽ được cập nhật. Nếu 2000 quá nhiều và bạn lại gặp vấn đề, bạn có thể điều chỉnh số sao cho nó nhỏ hơn.

Đã mất vài giờ để thử một số giải pháp trong số đó nhưng cuối cùng đã truy tìm được IPS (Hệ thống bảo vệ công cụ) của công ty bị rớt kết nối sau khi một lượng dữ liệu nhất định được truyền.

Đối với băng thông được chia sẻ, cố gắng sao chép khi tải ít hơn. Nếu không, hãy thử với một kết nối tốc độ cao. Nếu vẫn không hoạt động, vui lòng sử dụng lệnh bên dưới,

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

Và cố gắng nhân bản một lần nữa. Bạn có thể cần thay đổi các cài đặt đó theo kích thước bộ nhớ khả dụng của mình.

Nó có thể đơn giản như một vấn đề máy chủ. Nếu sử dụng GitHub, hãy kiểm tra https://twitter.com/githubstatus . Tôi đã nhìn thấy điều này lần đầu tiên ngay bây giờ và phát hiện ra GitHub đang có một sự chao đảo . Một vài phút sau nó hoạt động tốt trở lại.

Điều này làm việc cho tôi, thiết lập máy chủ tên Googles vì ​​không có máy chủ tên tiêu chuẩn nào được chỉ định, tiếp theo là khởi động lại mạng:

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

Tôi đã đối mặt với vấn đề này bằng cách sử dụng git trong Kubfox. Tôi cũng nhận thấy sự mất ổn định chung trong mạng và tìm ra giải pháp .

trong /etc/resolv.conf thêm dòng vào cuối tệp

tùy chọn yêu cầu duy nhất

Điều này đã cố định độ trễ trước mỗi độ phân giải tên miền và git bắt đầu hoạt động như một bùa mê sau này.

Tôi thấy vấn đề của mình là với tệp .netrc, nếu vậy với bạn thì bạn có thể làm như sau:

Mở tệp .netrc của bạn và chỉnh sửa nó để bao gồm thông tin đăng nhập github. Nhập nano ~/netrchoặcgedit ~/netrc

Sau đó bao gồm: * máy github.com

tên đăng nhập

mật khẩu bí mật

máy api.github.com

tên đăng nhập

mật khẩu bí mật *

Bạn có thể bao gồm mật khẩu thô của mình ở đó nhưng vì mục đích bảo mật, hãy tạo mã thông báo xác thực ở đây github mã thông báo và dán mật khẩu thay cho mật khẩu của bạn.

Hy vọng điều này sẽ giúp ai đó

Có thể là do kích thước của các cam kết đang được đẩy .. Phân tích số lần xác nhận theo các bước sau:

git log -5

Xem 5 cam kết cuối cùng và bạn sẽ biết những cam kết nào không được đẩy đến từ xa. Chọn một id xác nhận và đẩy tất cả các cam kết lên tới id đó:

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

LƯU Ý: Tôi vừa kiểm tra cam kết của mình có thể có kích thước lớn nhất; đầu tiên đẩy lên đến lúc đó Thủ thuật đã có hiệu quả. !!

Tôi đã thực hiện git đẩy từ OS X El Capitan Mac của tôi. Tôi đã gặp lỗi tương tự, tôi đã thử mọi cách để sửa, những gì tôi tìm thấy trên google / stackoverflow. Theo như phiên bản liên quan, tôi đang sử dụng phiên bản github khá mới nhất là 2.7.4. Tôi đã tạo một dự án trong hệ thống địa phương của mình và tôi muốn nó được công khai trong tài khoản github của mình. Quy mô dự án không khoảng 8MB. Tôi nhận thấy rằng khi tôi đang đẩy một số tệp có kích thước khoảng 1,5 MB, thì nó đã được đẩy đúng cách, nhưng với kích thước lớn không thành công đối với tôi, với cùng một lỗi,

Tùy chọn duy nhất tôi có là đẩy các thay đổi trong khối MB. Bây giờ tôi đã đẩy tất cả các thay đổi. Đây là cách giải quyết cho tôi cho đến khi tôi sửa lỗi cho giải pháp này.

Vì vậy, bạn cũng có thể thử đẩy thay đổi trong nhiều cam kết. Hoặc nếu bạn có nhiều thư mục, bạn có thể đẩy các thay đổi theo từng thư mục (nếu kích thước thư mục không lớn).

Hy vọng điều này sẽ giúp bạn tiếp tục làm việc trên dự án.

Đối mặt với cùng một vấn đề, cố gắng hợp nhất với một chi nhánh khác và lấy từ họ. Nó làm việc cho tôi như vậy.

sử dụng sshthay vì http, nó không phải là một câu trả lời tốt cho câu hỏi này nhưng ít nhất nó có hiệu quả với tôi