Github - 사이드밴드 패킷을 읽는 동안 예기치 않은 연결 끊김
저는 꽤 흥미로운 문제가 있습니다.몇몇 프로젝트를 bash to repo로 보내려고 했는데 최근에 보내는데 문제가 생겼습니다.
Enumerating objects: 27, done.
Counting objects: 100% (27/27), done.
Delta compression using up to 16 threads
Compressing objects: 100% (24/24), done.
Writing objects: 100% (25/25), 187.79 KiB | 9.39 MiB/s, done.
Total 25 (delta 1), reused 0 (delta 0), pack-reused 0
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly
재미있는 부분은 10분 전에 아무 문제없이 보낼 수 있다는 것입니다.
새로운 레포를 얻고, 새로운 파일을 만들고, 깃을 다시 설치하고,git config --global http.postBuffer 524288000◦ https.postBuffer 등등.데스크톱 버전도 동일한 이슈가 들어오는 것으로 설치합니다.
대부분 리액트 앱에 문제가 있습니다.
해결책 아는 사람?무엇이 잘못될 수 있습니까?
우선 네트워크 연결 안정성을 확인합니다.
네트워크 연결에 문제가 없으면 다른 솔루션을 사용해 보십시오.
리눅스에서
Git 명령을 실행하기 전에 명령줄에서 다음을 실행합니다.
export GIT_TRACE_PACKET=1
export GIT_TRACE=1
export GIT_CURL_VERBOSE=1
Windows에서
Git 명령을 실행하기 전에 명령줄에서 다음을 실행합니다.
set GIT_TRACE_PACKET=1
set GIT_TRACE=1
set GIT_CURL_VERBOSE=1
그 외:
git config --global core.compression 0
git clone --depth 1 <repo_URI>
# cd to your newly created directory
git fetch --unshallow
git pull --all
PowerShell 사용자의 경우:
$env:GIT_TRACE_PACKET=1
$env:GIT_TRACE=1
$env:GIT_CURL_VERBOSE=1
네트워크 문제일 수 있습니다.네트워크 속도가 너무 느리면 예기치 않게 연결이 끊어질 수 있습니다.
인터넷 상태가 양호하고 이 메시지가 계속 수신되는 경우 포스트 버퍼에 문제가 있을 수 있습니다.예를 들어 150 MiB로 늘리려면 다음 명령을 사용합니다.
git config --global http.postBuffer 157286400
http.postBuffer에 대한 git-config Documentation에 따르면:
원격 시스템에 데이터를 게시할 때 스마트 HTTP에서 사용하는 버퍼의 최대 크기(바이트)입니다.이 버퍼 크기보다 큰 요청의 경우 HTTP/1.1 및 Transfer-Encoding: chunked를 사용하여 대용량 팩 파일을 로컬로 만들지 않습니다.기본값은 1 MiB로 대부분의 요청에 충분합니다.
이 제한을 높이는 것은 청크 전송 인코딩을 비활성화하는 경우에만 효과적이므로 원격 서버 또는 프록시가 HTTP/1.0만 지원하거나 HTTP 표준과 호환되지 않는 경우에만 사용해야 합니다.이를 높이는 것은 일반적으로 대부분의 푸시 문제에 효과적인 해결책은 아니지만, 작은 푸시에도 전체 버퍼가 할당되기 때문에 메모리 소비를 크게 증가시킬 수 있습니다.
따라서 이는 서버에 문제가 발생하는 경우를 완화하는 것에 불과합니다.이렇게 하면 GitHub이나 GitLab.com 에 푸시 문제가 해결되지 않을 가능성이 높습니다.
저도 같은 문제가 있었습니다.저는 20000개의 파일이 있는 레포를 가지고 있고, 전체 레포의 크기는 약 5GB이며, 일부 파일은 10MB입니다.문제없이 Repo를 수행할 수 있었고 문제없이 복제할 수 있었습니다(시간이 좀 걸렸지만).하지만 매번 이 레포를 내 기계로 끌어당길 때마다
remote: Enumerating objects: 1359, done.
remote: Counting objects: 100% (1359/1359), done.
remote: Compressing objects: 100% (691/691), done.
remote: Total 1221 (delta 530), reused 1221 (delta 530), pack-reused 0
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
마침내 도움이 된 것은 이 팁이었습니다.사용자 디렉토리로 이동하여 편집.git/config추가:
[core]
packedGitLimit = 512m
packedGitWindowSize = 512m
[pack]
deltaCacheSize = 2047m
packSizeLimit = 2047m
windowMemory = 2047m
Voila. 더 이상의 오류는 없습니다.
위의 것들 중 어느 것도 나에게 통하지 않았습니다.git config --global pack.window 1
git config --global http.version HTTP/1.1
문제를 해결해 줬습니다.이전에 여러 개의 다른 github 저장소에서 대규모 커밋을 푸시할 수 없었습니다.
연결, VPN, 안티바이러스, 방화벽
가장 그럴듯한 이유.특히 깃이 최신 상태라면 업데이트할 수 있습니다.
가장 먼저 시도하는 것은 연결 상태를 확인하고 안정적인지 확인하는 것입니다.
저의 연결 상태는 훌륭합니다 ===> 잠시만요 VPN을 사용하고 계신가요?
=> 비활성화합니다.노력해보세요. (VPN은 그런 문제의 큰 원인입니다.)
아직도 안 되나요?==> 바이러스 백신과 방화벽을 확인합니다.
- 인터넷 마구간.
- VPN VPN => 대범
- 방화벽 및 바이러스 백신
- 최신식으로 익히다
작동하지 않는 경우 아래를 참조하십시오.
깃 캐시, 버퍼 및 메모리
https://stackoverflow.com/a/29355320/7668448
git 글로벌 구성 열기:
git config --global -e
다음 항목을 추가합니다.
[core]
packedGitLimit = 512m
packedGitWindowSize = 512m
[pack]
deltaCacheSize = 2047m
packSizeLimit = 2047m
windowMemory = 2047m
복제를 다시 시도합니다.
그게 안되면! =>
부분 페치(partial fetch) 방법을 시도하고 압축을 비활성화할 수 있습니다.
https://stackoverflow.com/a/22317479/7668448
한 번에 하나의 명령어
git config --global core.compression 0
git clone --depth 1 <repo_URI>
git fetch --unshallow
자세한 내용은 링크에 나와 있습니다.
믿고 싶지 않았지만 3번의 클론 실패 후 와이파이 연결(Mac)에서 유선 연결(Linux)로 전환하여 처음으로 작동했습니다.왜 그런지 모르겠어요!
제 경우에는 초기 커밋을 추진할 때 크기가 100MB가 넘는 파일이 몇 개 있었습니다.GitHub에서는 이를 허용하지 않기 때문에 "측면대역 패킷을 읽는 동안 예기치 않은 연결 끊김: 원격 끝이 예기치 않게 끊어졌습니다"라는 오류가 나타납니다.
gitm 사용으로는 부족해서 git in, git add, git commit, git push로 처음부터 다시 시작해야 문제가 해결할 수 있었습니다.
SSH URL을 사용하는 경우 다음을 시도할 수 있습니다. 두 번의 동일한 문제가 발생했을 때 효과가 있었습니다.
- URL로 HTTPS URL:
git remote set-url origin https://github.com/<your_repo> - 밀어주세요.지금 실패하면 안 됩니다.
- SSH: SSH로 합니다.
git remote set-url origin git@github.com:<your_repo>
그 문제의 원인이 무엇인지 아직 잘 모르겠습니다.이것은 단지 해결책일 뿐입니다.
제 경우에는 새로운 레포에 대한 첫 번째 커밋에서 이 오류가 발생했습니다.
나는 .git 폴더를 삭제한 다음 한 번에 몇 개의 파일을 추가하여 각각의 추가를 수행했습니다.
저는 같은 오류를 겪지 않고 모든 것을 다시 추가할 수 있었습니다.
윈도우용
set GIT_TRACE_PACKET=1
set GIT_TRACE=1
set GIT_CURL_VERBOSE=1
git init
그리고 필요한 프로젝트를 복제합니다. 나한테 효과가 있었습니다.
위의 제안들을 시도해 보았지만 성공하지 못했습니다.
제 문제가 경로 길이였던 것으로 드러났습니다.중첩된 디렉토리의 수(풍부한)인지 전체 경로 길이(경로 + 파일)인지 알 수 없습니다.
드라이브의 루트에서 복제했는데 작동했습니다(예, Windows 10).
업데이트: 분명히 하기 위해, 승인된 답변을 사용하여 드라이브의 루트에 복제해야 했습니다.
위의 어떤 것도 작동하지 않았지만 OpenSSH에서 pink로 전환하는 것은 작동하지 않았습니다.
$env:GIT_SSH="C:\ProgramData\chocolatey\bin\PLINK.EXE"
내 설정은:
- C:\windows\시스템32\열림SSH\ssh.exe(8.1.0.1)
- C:\Program Files\Git\cmd\git.exe (2.37.3.1)
- Microsoft Windows [버전 10.0.19044.2604]
윈도우 11에서는 내장 오픈을 업그레이드하여 이 문제를 해결했습니다.C에 있는 SSH:\Windows\시스템32\OpenSSH 폴더.
최신 바이너리를 다운로드 받을 수 있습니다: https://github.com/PowerShell/Win32-OpenSSH/releases
문제를 해결하는 릴리스 노트에서 #2012를 참조하십시오.
v9.2.2.0p1-Beta Latest
This is a beta-release (non-production ready)
This release includes:
Security Fixes:
Upgrade to LibreSSL 3.7.2. Please refer to https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.7.2-relnotes.txt
MSI: change inbound firewall rule that opens port 22 to apply to Private networks only
Non-Security Fixes:
Add U2F/Fido2 keys to the agent from other clients: #1961 - thanks @ddrown!
Fix output codepage after executing scp/sftp/ssh/ssh-keygen command: #2027 - thanks @kemaruya!
Fix early EOF termination when running git fetch over ssh: #2012 - thanks @cwgreene!
Revert mark-of-the-web for SCP/SFTP file downloads: #2029
프로젝트를 ssh가 아닌 https로 보내주시는 것 같습니다.사용해 봅니다.
ssh://git@host:port/path/name.git
.gitgonfig에서 SSL 검증이 켜져 있는지 확인합니다.
sslVerify = true
SSH 키가 없는 경우 생성하여 원격에 추가합니다.비트버킷의 예는 다음과 같습니다.
연결 중 키 수락
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
할 도 하지 에서 하지 도 에서 할 git fetch --unshallow를 수정하기 실행했습니다. 하기 를 로 는 로 는 를 하기 git guiUI 버전을 Windows에서 불러옵니다.그다음에 선택했습니다.
이것은 오류 없이 완성되었고, 그리고 나서 나는 그것을 할 수 있었습니다.git fetch --unshallow압박을 가하든지 하지 않든지
위의 모든 것을 시도해 보았지만 아무 것도 되지 않았습니다.
그래서 윈도우 11에서 Github Desktop(관리자로 열림)을 사용하여 새로운 저장소를 만들었고, 정상적인 파일 탐색기 작업을 통해 결함이 있는 저장소의 모든 파일을 새 저장소로 복사했습니다.저는 여전히 Github 데스크톱 앱을 사용하여 Github(원격)에 새로운 변경 사항을 적용했습니다.그런 다음 VScode에서 로컬 레포를 열었습니다.저는 지금 새로운 레포를 사용하고 있고 모든 것이 괜찮습니다.편집 후 성공적으로 푸시할 수 있게 되었습니다.
https 프로토콜을 통해 비트를 전송하는 문제입니다.대신 ssh를 사용하도록 git를 구성할 수 있습니다.
먼저 워크스테이션에 ssh-key를 만든 다음, 암호 없이 컴퓨터를 인증하기 위해 Github에 해당 키를 복사합니다.그런 다음 사용하도록 깃을 구성합니다.ssh https.
ssh키 생성
여기서 Github의 훌륭한 지침을 반복할 필요가 없습니다.
심플한 방법
clone 명령에 git 프로토콜 사용:
git clone git@github.com:repo-name
일반 방법: https 대신 ssh(git) 프로토콜을 사용하도록 git 구성
이 옵션은 GitHub Desktop을 사용하고 있고 클론 URL을 직접 제어하지 않는 경우에 좋습니다.
git config --global url."git@github.com:".insteadOf "https://github.com/"
Github 엔터프라이즈의 경우 퍼블릭 Github보다는 귀하의 인스턴스를 위한 현지 번역을 만드십시오.
이 후에는 이 오류 없이 복제할 수 있어야 합니다.
알 수 없는 이유로 인해 이전에 홈브루 설치 시도가 실패했습니다...이제 다음 명령을 사용하여 제거해야 합니다.
/bin/fsl -c "$(fsl https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh) )"
그런 다음 다음을 사용하여 다시 설치합니다.
/bin/fsl -c "$(fsl https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh) )"
오늘 갑자기 이런 문제가 생겼어요. 그 전날에도 똑같은 레포가 문제없이 작동했어요.Github 문서에 나와 있는 것처럼 Github 구성 패널에서 SSH 키를 삭제하고 다시 추가하여 해결했습니다.SSH 키를 새로 만들 필요가 없었습니다.
Vscode의 git GUI에서 푸시해 보십시오.그것은 나에게 효과가 있었다.
저는 라우터를 빨리 재부팅하면 문제가 해결되었습니다.다른 구성 변경은 필요하지 않았지만 상황은 다를 수 있습니다.
저는 비슷한 문제에 직면하여 리모트 url을 SSH url로 설정하여 해결하였습니다.
git remote set-url origin <SSH URL>
제 레포는 처음에 SSH로 복제되었다가 HTTPS로 변경되어 문제가 생겼습니다.그래서 리모트 오리진을 SSH로 다시 설정했고 정상적으로 작동하기 시작합니다.
이전 솔루션에 추가하여 이 문제를 해결한 것은 언급된 구성 값 외에 네트워크에서 점보 프레임을 비활성화하는 것이었습니다.
문제가 내 ISP인지 로컬(또는 심지어 Github)인지는 모르겠지만, 이 글을 읽는 사람에게 시도하는 것은 나쁘지 않습니다.
Windows(윈도우) 환경에서 자격 증명 관리자 경로가 결과를 가져오지 않은 경우 저장소의 로컬 복사본에 문제가 있을 수 있습니다.
일부 유지관리를 실행해야 할 수도 있습니다. 다음 명령어 집합도 내용을 제거하고 되돌릴 수 없도록 주의해야 합니다.
git fetch --prune // align local state
git branch -vv | grep -i 'gone' | awk '{print $1}' | xargs git branch -D // Delete branches marked as gone by the remote server
git fsck --full // verifies the connectivity and validity of the objects in the database
git reflog expire --expire=now --all // manage reflog information
git repack -a -d -l // pack unpacked objects in the repository
git gc --prune=now --aggressive // cleanup unnecessary files and optimize the local repository
댓글은 의도적으로 복사 붙여넣기 방식으로 사용자가 읽고 계속할지 결정할 수 있는 시간을 제공합니다.
이렇게 하면 원격 복사, dangling commit 및 기타 죽은 것에 의해 삭제된 것으로 표시된 로컬 분기가 모두가 제거됩니다.
로컬 복사본을 정리한 후 이전에 실패한 작업을 다시 시도할 수 있습니다.
위의 모든 옵션들이 저에게 그 문제를 해결해 주지 못했습니다.몇몇 사람들이 도움을 주고 초기 한계를 넘겼지만, 여전히 중간에 멈춰 있는 것을 발견했습니다.
문제는 커밋 기록에서 100mb 표시를 초과한 일부 대용량 파일로 인해 저장소를 가져올 수/클론/풀할 수 없다는 것이었습니다.또한 느린 인터넷으로 인해 문제를 온라인으로 푸시하기 전에 로컬에서 문제를 해결하기 위해 커밋한 기록이 남아 있는 나쁜 저장소를 가져올 수 없었습니다.
문제가 네트워크/인터넷 문제라고 지적한 일부 의견을 토대로 SSH 구성에 초점을 맞추고 문제 해결에 도움이 되는지 성능을 개선하기로 했습니다.그리고 비올라!!! 문제 해결.나는 여전히 이전 제안의 일부 구성, 특히 .git/config 캐시 설정과 관련된 구성을 유지했습니다.
[core]
packedGitLimit = 512m
packedGitWindowSize = 512m
[pack]
deltaCacheSize = 2047m
packSizeLimit = 2047m
windowMemory = 2047m
SSH confiation .ssh/config로 업데이트한 방법은 다음과 같습니다.
Git 다운로드 속도를 향상시키기 위해 SSH 클라이언트 구성을 수정하여 SSH 연결을 최적화할 수 있습니다.다음은 고려할 수 있는 몇 가지 구성 옵션입니다.
더 빠른 SSH 알고리즘 사용: 기본적으로 OpenSSH는 SSH 연결에 대해 ssh-rsa 알고리즘의 우선 순위를 지정합니다.그러나 일반적으로 ecdsa-sha2-nistp256 알고리즘이 더 빠릅니다.~/.ssh/config 파일에 다음 행을 추가하여 사용할 수 있습니다.
Host *
HostKeyAlgorithms ecdsa-sha2-nistp256,ssh-rsa
연결 다중화 사용: SSH 연결 다중화를 사용하면 기존 SSH 연결을 재사용할 수 있으므로 새로운 연결을 설정하는 데 드는 오버헤드를 크게 줄일 수 있습니다.연결 다중화를 사용하려면 ~/.ssh/config 파일에 다음 행을 추가합니다.
Host *
ControlMaster auto
ControlPath ~/.ssh/control:%h:%p:%r
ControlPersist yes
SSH 연결 시간 초과 증가:네트워크 속도가 느리거나 불안정한 경우 SSH 연결 시간 초과를 늘리면 조기 연결 종료를 방지할 수 있습니다.~/.ssh/config 파일에 다음 행을 추가하여 시간 초과를 60초로 늘립니다.
Host *
ServerAliveInterval 60
더 빠른 암호 사용:보다 빠른 암호 알고리즘을 사용하여 SSH 성능을 향상시킬 수 있습니다.그러나 선택한 암호를 지원하려면 원격 SSH 서버가 필요할 수 있습니다.예를 들어 aes128-gcm@openssh.com 암호를 사용하려면 ~/.cyclus/config 파일에 다음 행을 추가합니다.
Host *
Ciphers aes128-gcm@openssh.com
SSH 클라이언트 구성을 변경한 후 파일을 저장하고 Git을 다시 사용하여 다운로드 속도가 향상되었는지 확인합니다.
모든 것을 평가한 후 이를 조합하여 .ssh/config 파일 끝에 입력했습니다.
Host *
HostKeyAlgorithms ecdsa-sha2-nistp256,ssh-rsa
ControlMaster auto
ControlPath ~/.ssh/control:%h:%p:%r
ControlPersist yes
ServerAliveInterval 60
Ciphers aes128-gcm@openssh.com
SSH 구성 옵션을 수정할 때는 주의를 기울이고 보안에 유의해야 합니다.일부 옵션의 경우 원격 SSH 서버 및 해당 구성과 호환성이 필요할 수 있습니다.
위의 많은 제안들을 시도해 보았지만, 아무 것도 효과가 없었습니다.드디어 git 클라이언트를 2.37에서 2.41로 업그레이드해서 문제가 사라졌습니다.
참고로, "연결이 중단되었습니다"라는 무작위 메시지가 계속 나와서 PC에 문제가 있는 것 같은데, 이는 또 다른 이야기입니다.
언급URL : https://stackoverflow.com/questions/66366582/github-unexpected-disconnect-while-reading-sideband-packet
'programing' 카테고리의 다른 글
| 팬더는 행별 최소값을 두 개 이상의 열로 얻습니다. (0) | 2023.09.18 |
|---|---|
| mysql에 빅데이터를 저장하는 방법은? (0) | 2023.09.18 |
| 목록 항목 총알이 부동 요소와 겹치는 이유 (0) | 2023.09.18 |
| pdo가 와일드카드로 준비한 문 (0) | 2023.09.18 |
| AJAX를 통해 비디오를 읽은 후 blob을 (0) | 2023.09.18 |