자식 복제 중에 원격 끝이 예기치 않게 끊어졌습니다.

내 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 configman 페이지 , http.postBuffer약 :

원격 시스템에 데이터를 POST 할 때 스마트 HTTP 전송에 사용되는 버퍼의 최대 크기 (바이트)입니다.
이 버퍼 크기보다 큰 요청의 경우 HTTP / 1.1 Transfer-Encoding: chunked은 대규모 팩 파일을 로컬로 작성하지 않도록하는 데 사용됩니다. 기본값은 1MiB이며 대부분의 요청에 충분합니다.

클론의 경우에도 효과가있을 수 있으며이 경우 OP Joe 는 다음과 같이보고합니다.

[복제]는 지금 잘 작동

참고 : 서버 측에서 문제가 발생하고 서버가 Git 2.5 이상 (Q2 2015)을 사용하는 경우 오류 메시지가보다 명확 할 수 있습니다.
" 깃트 클로닝 : 원격 엔드가 예기치 않게 끊어져 변경을 시도 postBuffer했지만 여전히 실패 "를 참조하십시오.

Kulai ( 의견에 의하면 )는 이 Atlassian Troubleshooting Git 페이지 를 가리키며 다음을 추가합니다.

Error code 56curl이 오류를 수신했음을 나타내며 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 년 2 월)을 사용하면이 http.postBuffer"솔루션" 에 대해 더 많이 알 수 있습니다 .

brian m의 commit 7a2dc95 , commit 1b13e90 (2020 년 1 월 22 일)을 참조하십시오 . 칼슨 ( bk2204) .
^{(가 합병 - Junio C 하마노 gitster- 에 53a8329 커밋 2020 30 년 1 월)}
( 망할 놈의 메일 링리스트의 토론을 )

docs: http.postBuffer를 늘릴 때 언급 할 가치가있다

^{서명자 : brian m. 칼슨}

다양한 상황의 사용자는 HTTP 푸시 문제에 직면합니다.

종종 이러한 문제는 바이러스 백신 소프트웨어, 프록시 필터링 또는 기타 중간자 상황으로 인해 발생합니다. 다른 경우에는 네트워크의 단순 불안정성 때문입니다.

그러나 온라인에서 발견 된 HTTP 푸시 문제에 대한 일반적인 해결책은 http.postBuffer를 늘리는 것입니다.

이는 위에서 언급 한 상황 중 어느 것도 작동하지 않으며 매우 제한적인 소수의 경우에만 유용합니다. 본질적으로 연결이 HTTP / 1.1을 제대로 지원하지 않는 경우에 유용합니다.

이 값을 올릴 때 적절하고 실제로하는 일을 문서화하고 사람들이 푸시 문제에 대한 일반적인 해결책으로 사용하지 않도록하십시오. 효과적이지 않기 때문입니다.

따라서 현재 문서 git config http.postBuffer에는 다음이 포함됩니다.

http.postBuffer

원격 시스템에 데이터를 POST 할 때 스마트 HTTP 전송에 사용되는 버퍼의 최대 크기 (바이트)입니다.
이 버퍼 크기보다 큰 요청의 경우 HTTP / 1.1 및 Transfer-Encoding : chunked는 대규모 팩 파일을 로컬로 작성하지 않도록하기 위해 사용됩니다.
기본값은 1MiB이며 대부분의 요청에는 충분하지 않습니다.

이 제한을 높이는 것은 청크 전송 인코딩을 비활성화하는 데만 유효하므로 원격 서버 또는 프록시가 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를 사용하는 것입니다.

GnuTLS 대신 OpenSSL로 Git을 컴파일하기 위해 다른 곳에 게시 된 솔루션을 보았습니다 . 이 문제에 대한 활성 버그 보고서가 있습니다 .

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 .: 변화 http.postBuffer 또한 하려면 client_max_body_size의 값을 조정하여 gitlab이 클라이언트의 더 큰 바디 크기를 허용하도록 Nginx 구성 파일을 설정해야 할 수도 있습니다.

그러나 Gitlab 머신 또는 네트워크의 머신에 액세스 할 수 있고이를 사용하는 경우 해결 방법이 있습니다git bundle .

1. 소스 머신의 git 저장소로 이동하십시오.
2. 운영 git bundle create my-repo.bundle --all
3. my-repo.bundle 파일을 대상 컴퓨터로 전송 (예 : rsync 사용)
4. 대상 컴퓨터에서 실행 git clone my-repo.bundle
5. git remote set-url origin "path/to/your/repo.git"
6. git push

모두 제일 좋다!

나를 위해 일한 유일한 것은 SSH 링크 대신 HTTPS 링크를 사용하여 repo를 복제하는 것입니다 .

https를 사용 중이고 오류가 발생하는 경우

http 대신 https를 사용하여 문제를 해결했습니다.

git config --global https.postBuffer 524288000

이 답변을 기반으로 https 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를하는 것은 함께 할 (우연히 발견) 어떤 REPO 크기, 작동 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"로 시작했습니다.

"git config --global core.compression 4"가 저에게 효과적이었습니다.

이것은 인터넷 연결 문제로 인해 동일한 문제에 직면했습니다. 나는 코드의 얕은 사본을 사용하여

git clone --depth 1 //FORKLOCATION

나중에 클론을 사용하여 복제를 해제했습니다

git fetch --unshallow

에서 /etc/resolv.conf파일의 끝에 행을 추가

options single-request

글쎄, 나는 219 MB 솔루션을 추진하고 싶었지만 운이 없었습니다.

git config --global http.postBuffer 524288000

그리고 어쨌든 525MB의 포스트 버퍼를 갖는 것이 무엇입니까? 바보입니다. 그래서 아래의 자식 오류를 보았습니다.

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은 5MB를 게시하고 싶은데 포스트 버퍼를 6MB로 만들었습니다.

git config --global http.postBuffer 6291456

나는 같은 문제가 있었고 인터넷 연결이 좋지 않아서 git 설정을 시도한 후에 네트워크에서 연결을 끊고 다시 연결했는데 작동합니다!.

연결이 끊어지면 (또는이 상황을 발생시키는 작업) git이 멈추는 것 같습니다.

나는 그것이 더 많은 누군가에게 도움이되기를 바랍니다.

베스트,

나도 같은 문제가 있었는데이 문제의 이유는 GNUTLS에 대한 Kurtis의 설명 때문이다.

동일한 이유가 있고 시스템이 Ubuntu 인 경우에서 최신 버전의 git을 설치하여이 문제를 해결할 수 있습니다 ppa:git-core/ppa. 명령은 다음과 같습니다.

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

탄력적 beantalk로 관리되는 AWS EC2 인스턴스에서 호스팅되는 원격 git repo에서 데이터를 HTTP로 복제 할 때이 문제에 직면했습니다. 복제 자체도 AWS EC2 인스턴스에서 수행되었습니다.

위에서 언급 한 모든 솔루션과 그 조합을 시도했습니다.

• 자식 설정 http.postBuffer
• 환경http.maxrequestbuffer
• git 압축을 해제하고 "shallow"를 시도한 git clone후 git fetch --unshallow-참조 치명적 : 초기 EOF 치명적 : index-pack failed
• GIT 메모리 설정 튜닝- packedGitLimit 기타, 여기 참조 : 치명적 : 초기 EOF 치명적 : 인덱스 팩 실패
• nginx 구성 시작-설정 client_max_body_size 큰 값과 0으로 설정 (무제한); 환경proxy_request_buffering off;
• 환경 options single-request/etc/resolv.conf의
• 물방울을 사용 하여 자식 클라이언트 처리량 조절
• 추적에 strace 사용 git clone
• 자식 클라이언트 업데이트 고려

이 모든 후에도 문제가 ELB (Elastic Load Balancer)에서 연결을 끊는다는 것을 알 때까지 계속해서 같은 문제에 계속 직면하고있었습니다 . ELB를 거치지 않고 EC2 인스턴스 (git repo를 호스팅하는 인스턴스)에 직접 액세스 한 후 마침내 git repo를 복제했습니다! ELB (timeout) 매개 변수 중 어느 것이이 작업을 담당하는지 확실하지 않으므로 아직 조사를해야합니다.

최신 정보

Connection Draining 정책 변경시간 초과를 20 초에서 300 초로 늘려 AWS Elastic Load Balancer에 대한 을 하면이 문제가 해결 된 것 같습니다.

git clone오류와 "연결 배수" 사이의 관계 는 이상하고 우리에게는 분명하지 않습니다. 연결 드레 이닝 시간 초과 변경으로 인해 ELB 구성에서 일부 내부 변경이 발생하여 조기 연결 종료 문제를 해결했을 수 있습니다.

이것은 AWS 포럼의 관련 질문입니다 (아직 답변 없음) : https://forums.aws.amazon.com/thread.jspa?threadID=258572

나는 비슷한 문제가 있었지만 대나무 일을했다. Bamboo는 캐시 된 리포지토리의 로컬 클론 (로컬이지만 SSH 프록시를 통해)을 수행하는 데 실패했습니다. 캐시를 삭제 한 후 작동했지만 로컬 캐시에서 복제하려고 할 때마다 실패했습니다. 대나무의 SSH 프록시 버전에 문제가있는 것 같습니다.

BitBucket을 사용하는 동안 동일한 오류가 있습니다. 내가 한 것은 내 repo의 URL에서 https를 제거하고을 사용하여 URL을 설정하는 것 HTTP입니다.

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

WIFI 라우터 설정으로 해결 :

설정 PPPoE (WiFi 라우터로 자동 로그인)를 사용하여 Wi-Fi에있을 때 동일한 문제가 발생했습니다.

Git 다운로드 속도는 15kb로 매우 느립니다.

packet_write_wait : 17.121.133.16 포트 22에 연결 : 파이프 치명적 손상 : 원격 끝이 예기치 않게 치명적 임 : EOF 치명적 : 인덱스 팩 실패

해결 방법 : 1. 동적 IP로 설정을 변경하고 wifi 라우터를 재부팅합니다. 2. 웹 브라우저 로그인에서 인터넷 서비스 제공 업체 포털로 (Wi-Fi 라우터에서 PPPoE, 자동 로그인을 구성하지 마십시오).

Git 다운로드 속도를 변경 한 후 1.7MiB입니다.

이것은 내 문제를 해결했다.

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

레포가 github에서 허용되는 최대 푸시 크기보다 커서 위의 트릭은 도움이되지 않았습니다. 작동 한 것은 https://github.com/git-lfs/git-lfs/issues/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 (Instrusion Protection System)로 추적했습니다.

공유 대역폭의 경우로드가 적을 때 복제를 시도하십시오. 그렇지 않으면 고속 연결로 시도하십시오. 여전히 작동하지 않으면 아래 명령을 사용하십시오.

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의 흔들림을 발견했습니다 . 몇 분 후 다시 정상적으로 작동했습니다.

표준 네임 서버가 지정되지 않았기 때문에 Google 네임 서버를 설정 한 다음 네트워킹을 다시 시작했습니다.

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

쿠분투에서 git을 사용 하여이 문제에 직면했습니다. 또한 네트워킹의 전반적인 불안정성을 발견하고 해결책을 찾았습니다 .

/etc/resolv.conf에서 파일 끝에 줄을 추가하십시오.

단일 요청 옵션

이로 인해 모든 도메인 이름 확인 및 git이 이후 ​​매력처럼 작동하기 전에 지연되었습니다.

내 문제는 .netrc 파일과 관련이 있다는 것을 알았습니다. 그렇다면 귀하도 다음을 수행 할 수 있습니다.

.netrc 파일을 열고 github 자격 증명을 포함하도록 편집하십시오. 유형 nano ~/netrc또는gedit ~/netrc

그런 다음 다음을 포함하십시오 : * machine github.com

로그인 사용자 이름

비밀 번호 비밀

기계 api.github.com

로그인 사용자 이름

비밀 번호 *

당신은 당신의 원시 암호를 포함 할 수 있지만 보안을 위해 여기 github 토큰에 인증 토큰을 생성하십시오 하여 비밀번호 대신 붙여 넣으십시오.

이것이 누군가를 돕기를 바랍니다.

푸시되는 커밋 크기 때문일 수 있습니다. 다음 단계에 따라 커밋 수를 분류하십시오.

git log -5

마지막 5 개의 커밋을 확인하면 어떤 것이 커밋되지 않았는지 알 수 있습니다. 커밋 ID를 선택하고 모든 커밋을 해당 ID로 푸시하십시오.

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

참고 : 방금 커밋을 확인했는데 가장 큰 크기를 가질 수 있습니다. 그때까지 먼저 밀어 올렸습니다. 트릭은 효과가 있었다!!

OS X El Capitan Mac에서 git push를하고있었습니다. 나는 같은 오류가 발생했습니다. 모든 문제를 해결하려고 시도했습니다 .google / stackoverflow에서 발견했습니다. 버전에 관해서는 2.7.4 인 github의 최신 버전을 사용하고 있습니다. 로컬 시스템에서 프로젝트를 만들었으며 github 계정에서 공개하기를 원했습니다. 프로젝트 크기는 약 8MB가 아니 었습니다. 크기가 1.5MB 정도 인 일부 파일을 푸시 할 때 제대로 푸시되었지만 큰 크기로 실패했지만 동일한 오류가 발생했습니다.

내가 가진 유일한 옵션은 MB 단위로 변경 사항을 푸시하는 것이 었습니다. 이제 모든 변경 사항을 적용했습니다. 이 솔루션에 대한 수정 사항을 얻을 때까지이 문제가 해결되었습니다.

따라서 다중 커밋에서 변경 사항을 푸시 할 수도 있습니다. 또는 폴더가 여러 개인 경우 각 폴더별로 변경 사항을 적용 할 수 있습니다 (폴더 크기가 크지 않은 경우).

이것이 프로젝트 작업을 계속하는 데 도움이되기를 바랍니다.

같은 문제에 직면하여 다른 지사와 합병하여 끌어냅니다. 그것은 나를 위해 동일하게 작동합니다.

ssh대신에 사용 http하면이 질문에 대한 좋은 대답은 아니지만 적어도 그것은 나를 위해 작동합니다