programing

git 복제 중 원격 종료가 예기치 않게 끊어졌습니다.

javamemo 2023. 5. 5. 08:32
반응형

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

)npm publishMartin Braun은 코멘트에서 기본값 1 000이 아닌 50 000 이하로 설정했다고 보고합니다.)

###추가 정보:

맨 페이지에서.http.postBuffer내용:

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

클론의 경우에도 영향을 미칠 수 있으며, 이 경우 OP Joe는 다음과 같이 보고합니다.

[clone] 이제 잘 작동합니다.

참고: 서버 측에서 문제가 발생하고 서버가 Git 2.5+(2015년 2분기)를 사용하는 경우 오류 메시지가 더 분명할 수 있습니다.
Git cloning: 원격 엔드가 예기치 않게 끊어졌습니다. 변경을 시도했지만 여전히 실패했습니다.를 참조하십시오.

Kulai(댓글)는 다음과 같이 추가된 이 Atlassian Troubleshooting 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

22월)을 하면 이 Git 2.25.1(2020년 2월)에 더 알 수 .http.postBuffer"고집"

commit 7a2dc95, brian m. Carlson()bk2204의 commit 1b13e90(2020년 1월 22일)을 참조하십시오.
(주니오 C 하마노에 의해 합병 -- 53a8329, 2020년 1월 30일 커밋)
(Git 메일링 목록 토론)

http.postBuffer를 늘릴 때 docs언급합니다.

사인 오프 바이: 브라이언 칼슨.

다양한 상황에서 사용자는 HTTP 푸시 문제를 겪고 있습니다.

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

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

이 기능은 위에서 언급한 상황에서 작동하지 않으며 소수의 매우 제한된 경우에만 유용합니다. 기본적으로 연결이 HTTP/1.1을 제대로 지원하지 않는 경우입니다.

이 값을 높이는 것이 적절하고 실제로 무엇을 하는지 문서화하고, 사람들이 이 값을 푸시 문제에 대한 일반적인 해결책으로 사용하는 것을 단념합니다. 왜냐하면 그것은 그곳에서는 효과적이지 않기 때문입니다.

따라서 현재 설명서에는 다음이 포함됩니다.

http.postBuffer

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

이 제한을 높이면 청크 전송 인코딩을 사용할 수 없게 되므로 원격 서버 또는 프록시가 HTTP/1.0만 지원하거나 HTTP 표준을 준수하지 않는 경우에만 사용해야 합니다.
이를 높이는 것은 일반적으로 대부분의 푸시 문제에 효과적인 솔루션은 아니지만 작은 푸시에도 전체 버퍼가 할당되기 때문에 메모리 소비를 크게 늘릴 수 있습니다.

비트 버킷에 동일한 오류가 있습니다.고정자

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

이 답변을 바탕으로 (https url을 사용하여) 다음을 시도했습니다.

  1. repo의 초기 복제:

git clone --depth 25 url-here

  1. 시도당 두 번씩 증가하는 fetch 커밋:

git fetch --depth 50

git fetch --depth 100

git fetch --depth 200

...등

  1. 결국 (충분히 얻어졌다고 생각할 때) 나는 달립니다.git fetch --unshallow이제 끝입니다.

이 과정은 분명히 훨씬 더 많은 시간이 걸리지만, 제 경우 설정은http.postBuffer그리고.core.compression도움이 되지 않았습니다.

업데이트: SSH를 통해 가져오기는 모든 리포 크기(우연히 발견됨)에 대해 작동한다는 것을 알게 되었습니다.git clone <ssh url>SSH 키를 생성한 경우. repo를 사용하여 합니다.git remote set-url <https url to repo>

SSH 링크 대신 HTTPS 링크를 사용하여 복제를 수행하는 것이 유일하게 제게 효과적이었습니다.

이것은 인터넷 연결 문제 때문입니다, 저도 같은 문제에 직면했습니다.다음을 사용하여 얕은 코드 복사를 수행했습니다.

git clone --depth 1 //FORKLOCATION

나중에 다음을 사용하여 복제를 허용하지 않습니다.

git fetch --unshallow

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

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

그리고 다시 복제를 시도합니다.사용 가능한 메모리 크기에 따라 이러한 설정을 변경해야 할 수도 있습니다.

. 변경: 변경http.postBuffer또한 client_max_body_size 값을 조정하여 클라이언트에 대해 더 큰 신체 크기를 허용하도록 gitlab용 Nginx 구성 파일을 설정해야 할 수도 있습니다.

그러나 Gitlab 시스템이나 네트워크의 시스템에 액세스할 수 있는 경우에는 다음과 같은 방법을 사용하여 해결할 수 있습니다.git bundle.

  1. 소스 시스템의 Git 저장소로 이동합니다.
  2. 려달을 git bundle create my-repo.bundle --all
  3. my-repo를 전송합니다(예: rsync 사용).대상 시스템에 파일 번들
  4. 에서 를 합니다.git clone my-repo.bundle
  5. git remote set-url origin "path/to/your/repo.git"
  6. git push

좋은 일만 가득하시길요!

만약 당신이 https를 사용하고 있고 오류가 발생하고 있다면.

나는 http 대신 https를 사용했고 그것은 내 문제를 해결했습니다.

git config --global https.postBuffer 524288000

아래 명령을 사용한 후 솔루션을 얻었습니다.

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

저도 같은 문제가 발생했고, 시행착오 방식으로 수정했습니다.core.compression 값이 작동할 때까지 변경했습니다.

3번의 시도 끝에 "git config --global core.compression 1"로 시작했습니다.

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

219MB의 솔루션을 적용하고 싶었지만 운이 없었습니다.

git config --global http.postBuffer 524288000

어쨌든 525MB의 포스트 버퍼가 있는 이유는 무엇입니까?바보 같은 짓입니다.그래서 아래의 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

그래서 5MB를 올리고 싶어요, 그리고 나서 6MB의 포스트 버퍼를 만들었고, 그것은 작동합니다.

git config --global http.postBuffer 6291456

Elastic Beanstalk에서 관리하는 AWS EC2 인스턴스에서 호스트되는 원격 Gitrepo에서 HTTP를 통해 데이터를 복제할 때 이 문제에 직면했습니다.복제 자체도 AWS EC2 인스턴스에서 수행되었습니다.

앞서 언급한 모든 솔루션과 그 조합을 사용해 보았습니다.

  • 팅셋깃으로 http.postBuffer
  • http.maxrequestbuffer
  • " git 시도하기 축압제해실 "및행도" 시실도시git clone그리고 나서.git fetch --unshallow치명적 참조: 초기 EOF 치명적: 인덱스 팩 실패
  • 설정 - GIT 메모리 설정 -packedGitLimit예를 들어, 여기를 참조하십시오. 치명적: 초기 EOF 치명적: 인덱스 팩 실패
  • - nginx 설정 - 설정client_max_body_size 값 및 0(로 0(으)로 설정proxy_request_buffering off;
  • 팅세options single-request/etc/sysv.
  • 조절 git 클라이언트 처리량(트리플 포함)
  • 하여 적에추사용을 git clone
  • Git 클라이언트 업데이트 고려 중

이 모든 일이 있은 후에도 저는 연결을 끊는 Elastic Load Balancer(ELB)에 문제가 있다는 것을 발견할 때까지 계속해서 같은 문제에 직면했습니다.ELB를 거치지 않고 EC2 인스턴스(gitrepo를 호스팅하는 인스턴스)에 직접 액세스한 후 마침내 gitrepo를 복제할 수 있었습니다!저는 아직 어떤 ELB(타임아웃) 파라미터가 원인인지 확실하지 않아서 조사를 해야 합니다.

갱신하다

시간 초과를 20초에서 300초로 높여 AWS Elastic Load Balancer에 대한 연결 삭제 정책을 변경하여 이 문제를 해결한 것 같습니다.

의 git clone오류 및 "연결 배출"은 우리에게 이상하고 명확하지 않습니다.연결 배출 시간 초과 변경으로 인해 ELB 구성에서 일부 내부 변경이 발생하여 연결이 조기에 닫히는 문제가 해결되었을 수 있습니다.

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

/etc/resolv.conf의 합니다.

options single-request

저도 같은 문제가 있었고 인터넷 연결 불량과 관련이 있었습니다. 그래서 몇 가지 Git 구성을 사용해 본 후 네트워크에서 연결을 끊고 다시 연결하면 작동합니다!

연결이 끊긴 후(또는 이 상황을 발생시키는 작업) 깃이 고착된 것 같습니다.

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

최고야.

저도 같은 문제를 겪었습니다.이 문제의 이유는 GNUTLS에 대한 Kurtis의 설명과 같습니다.

Ubuntu인 에는 Ubuntu의 하여 이 할 수 .ppa:git-core/ppa과 같습니다.명령어는 다음과 같습니다.

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

이러한 솔루션 중 일부를 시도하는 데 몇 시간이 걸렸지만 결국 기업 IPS(침입 방지 시스템)가 일정량의 데이터를 전송한 후 연결을 끊는 것으로 추적했습니다.

postBuffer 크기와 maxRequestBuffer를 늘리면 이 문제에 도움이 됩니다.단계를 따라가면 됩니다.

단계:

1. 터미널 또는 Git Bash를 열고 "cd"를 사용하여 repo를 복제할 위치로 이동합니다.

2.압축을 0으로 설정

git config --global core.compression 0

3.postBuffer 크기 설정

git config --global http.postBuffer 1048576000

4.maxRequestBuffer 크기 설정

git config --global http.maxRequestBuffer 100M

5.이제 클론 시작

git clone <repo url>

6.클론이 완료될 때까지 기다립니다.

감사해요.해피 코딩!!!

저도 비슷한 문제가 있었지만, 대나무로 만든 일이 있었습니다.Bamboo가 캐시된 저장소의 로컬 복제(SSH 프록시를 통해 로컬 복제)에 실패하여 캐시를 삭제한 후 작동했지만 로컬 캐시에서 복제를 시도할 때마다 오류가 발생합니다.대나무 버전의 SSH 프록시 자체에 문제가 있는 것 같습니다.

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

/etc/sysv.conf에서 파일 끝에 줄을 추가

옵션 단일 요청

이 고정된 지연은 모든 도메인 이름 해결 전에 발생하고 이후에 매력적으로 작동하기 시작했습니다.

WIFI 라우터 설정으로 해결:

Settings PPPoE(WiFi 라우터에 의한 자동 로그인)로 와이파이를 할 때도 같은 문제가 발생했습니다.

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

packet_write_wait: 17.121.133.16 포트 22에 연결: 파이프 손상 치명적:원격 종료가 예기치 않게 치명적으로 중단되었습니다. 초기 EOF 치명적: 인덱스 팩 실패

해결책 : 1. 동적 IP로 설정 변경, wifi 라우터 재부팅, 2. 웹브라우저 로그인에서 인터넷 서비스 제공자 포털(PPPoE 구성 안 함, wifi 라우터에서 자동 로그인)

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

사용하다ssh에 http에게는 효과가 .

이것으로 문제가 해결되었습니다.

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개가 너무 많은데 문제가 다시 발생하면 숫자를 더 작게 조정할 수 있습니다.

나는 그것을 위해 가지 깃발을 제거해야 했습니다.git clone지휘권

MacOSX High Sierra에서 저를 위한 솔루션은 다음과 같습니다.

brew install git-lfs

오류 없이 저장소가 복제되었습니다.

서버 문제만큼 간단할 수도 있습니다.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

.netrc 파일에 문제가 있다는 것을 알게 되었습니다. 당신도 그렇다면 다음을 수행할 수 있습니다.

증명을 합니다.netrc 파일을 열고 github 자격 증명을 포함하도록 편집합니다. 형nano ~/netrc또는gedit ~/netrc

그런 다음 *machine github.com 을 포함합니다.

로그인 사용자 이름

비밀번호 비밀번호

기계 api.github.com

로그인 사용자 이름

비밀번호 비밀번호*

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

이것이 누군가에게 도움이 되기를 바랍니다.

비트버킷을 사용할 때도 같은 오류가 발생합니다.가 한 은 제 하고 https를 사용하여 입니다.HTTP.

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

언급URL : https://stackoverflow.com/questions/6842687/the-remote-end-hung-up-unexpectedly-while-git-cloning

반응형

'programing' 카테고리의 다른 글

PostgreSQL: Postgre에 테이블 표시SQL  (0) 2023.05.05
명령줄 인수를 사용하여 PostgreSQL .sql 파일 실행  (0) 2023.05.05
상수에 대한 C# 명명 규칙?  (0) 2023.05.05
asp.net 외부에서 레이저 뷰 엔진을 사용할 수 있습니까?  (0) 2023.05.05
잡기 및 다시 던지기에 대한 모범 사례.NET 예외  (0) 2023.05.05

'programing'의 다른글

  • 현재글git 복제 중 원격 종료가 예기치 않게 끊어졌습니다.

관련글

댓글

티스토리툴바