git clone中にリモートエンドが突然ハングアップした

私の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

（以下のコメントの一部は値を2倍にする必要があることを報告しています）：

git config --global http.postBuffer 1048576000

詳しくは：

以下からのgit configmanページ、http.postBufferおよそ次のとおりです。

リモートシステムにデータをPOSTするときにスマートHTTPトランスポートによって使用されるバッファの最大サイズ（バイト単位）。
このバッファーサイズより大きいリクエストの場合、HTTP / 1.1は、Transfer-Encoding: chunkedローカルで大規模なパックファイルを作成しないようにするために使用されます。デフォルトは1 MiBで、ほとんどのリクエストに十分です。

クローンについても影響を与える可能性があり、この場合、OP Joeは次のように報告します。

[クローン]正常に動作するようになりました

注：サーバー側で問題が発生し、サーバーがGit 2.5+（2015年第2四半期）を使用している場合、エラーメッセージはより明確になる可能性があります。
「Gitのクローン作成：リモートエンドが予期せずハングアップし、変更を試みpostBufferたが失敗する」を参照してください。

Kulai（コメント内）は、このAtlassianトラブルシューティング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「ソリューション」について詳しく知ることができます。

コミット7a2dc95、コミット1b13e90（2020年1月22日）のbrian mをbk2204参照してください。カールソン（）。
^{（による合併Junio C浜野- gitster-で53a8329をコミットし、2020年1月30日）}
（Gitのメーリングリストの議論）

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を使用して、ローカルで大規模なパックファイルが作成されないようにします。
デフォルトは1 MiBであり、ほとんどのリクエストに十分です。

この制限の引き上げは、チャンク転送エンコーディングを無効にする場合にのみ有効であるため、リモートサーバーまたはプロキシが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.postBufferclient_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リンクを使用してリポジトリを複製することでした。

httpsを使用していて、エラーが発生している場合。

httpではなくhttpsを使用して問題を解決しました

git config --global https.postBuffer 524288000

この回答に基づいて、私は（https URLで）以下を試しました：

1. リポジトリの最初のクローン：

git clone --depth 25 url-here

2. 試行深度ごとに2回増加してコミットをフェッチします。

git fetch --depth 50

git fetch --depth 100

git fetch --depth 200

...等々

3. 最終的には（十分にフェッチされたと思うと）、実行しますgit fetch --unshallow。

プロセスには明らかにはるかに長い時間がかかりますが、私の場合、設定http.postBufferでcore.compression助けにはなりませんでした。

UPD：sshキーを作成した場合、sshを介したフェッチは、（誤って検出された）任意のレポサイズで機能することがわかりましたgit clone <ssh url>。リポジトリが取得されたら、次を使用してリモートアドレスを変更しますgit remote set-url <https url to repo>

以下のコマンドを使用した後、解決策を得ました：

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

同じ問題が発生したので、試行錯誤で修正しました。それが機能するまで、core.compressionの値を変更しました。

3回試行した後、「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

とにかく525 MBのポストバッファを持っていることの意味は何ですか？それはばかげています。だから私は以下の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

gitは5 MBをポストしたいので、ポストバッファを6 MBにしたところ、うまくいきました。

git config --global http.postBuffer 6291456

私は同じ問題を抱えていましたが、それはインターネット接続の不良に関連していたため、いくつかのgit構成を試した後、ネットワークから切断して再接続したところ、動作しました！。

接続が失われた（またはこの状況を引き起こすアクション）後、gitが動かなくなったようです。

私はそれがここでもっと誰かのための助けになることを願っています。

ベスト、

私も同じ問題を抱えていました。この問題の理由は、KurtisのGNUTLSに関する説明と同じです。

同じ理由でシステムがUbuntuの場合、最新バージョンのgitをからインストールすることでこの問題を解決できppa:git-core/ppaます。コマンドは次のとおりです。

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

Elastic Beanstalkで管理されているAWS EC2インスタンスでホストされているリモートgitリポジトリからデータを（HTTP経由で）クローンするときにこの問題に直面していました。複製自体もAWS EC2インスタンスで行われました。

私は前述のすべての解決策とそれらの組み合わせを試しました：

• Gitの設定 http.postBuffer
• 設定http.maxrequestbuffer
• git圧縮をオフにして「浅い」git cloneを試みてからgit fetch --unshallow-参照致命的：初期EOF致命的：インデックスパックが失敗しました
• GITメモリ設定の調整- packedGitLimit 他、ここを参照：致命的：初期EOF致命的：インデックスパックが失敗しました
• nginx構成の調整-設定 client_max_body_size大きな値と0（無制限）の両方にします。設定proxy_request_buffering off;
• 設定 options single-request/etc/resolv.confの
• トリクルで gitクライアントのスループットを調整する
• トレースにstraceを使用する git clone
• gitクライアントの更新を検討しています

これがすべて終わった後も、Elastic Load Balancer（ELB）が接続を切断していることが問題になるまで、同じ問題に何度も直面していました。ELBを経由する代わりにEC2インスタンス（git repoをホストしているインスタンス）に直接アクセスした後、ようやくgit repoのクローンを作成しました！ELB（タイムアウト）パラメーターのどれがこれの原因であるかはまだわからないので、まだ調査が必要です。

更新

接続ドレインポリシーを変更しているようですタイムアウトを20秒から300秒に上げることでAWS Elastic Load Balancerのこの問題が解決したようです。

との関係 git cloneエラーと「接続ドレイン」は奇妙で、私たちには明らかではありません。接続ドレインのタイムアウトの変更により、ELB構成にいくつかの内部変更が発生し、接続が途中で終了する問題が修正された可能性があります。

これはAWSフォーラムの関連質問です（まだ回答はありません）：https : //forums.aws.amazon.com/thread.jspa?threadID=258572

私も同じような問題を抱えていましたが、竹職でした。キャッシュされたリポジトリのローカルクローン（ローカルだがSSHプロキシ経由）の実行にBambooが失敗していたので、キャッシュを削除しましたが、その後機能しましたが、ローカルキャッシュからクローンしようとすると失敗します。竹自体のバージョンのSSHプロキシにgit自体ではなく問題があるようです。

BitBucketの使用中に同じエラーが発生します。私がしたことは、私のリポジトリのURLからhttpsを削除し、を使用してURLを設定することHTTPでした。

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

WIFIルーター設定で解決：

設定PPPoE（wifiルーターによる自動ログイン）でwifiを使用しているときにも同じ問題が発生しました。

Gitのダウンロード速度は15kbと非常に遅いです。

packet_write_wait：17.121.133.16ポート22への接続：壊れたパイプ致命的：リモートエンドが突然ハングしました致命的：早期EOF致命的：インデックスパックが失敗しました

解決策：1.設定を動的IPに変更し、WiFiルーターを再起動します。2. Webブラウザーログインからインターネットサービスプロバイダーポータルへ（PPPoEを構成しないでください。Wi-Fiルーターからの自動ログイン）。

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ずつプッシュされます。（もちろん、両方の場所で別のブランチに置き換えることもできます。）これが完了すると、マスターを最後に1回プッシュでき、最新の状態になります。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

Kubuntuでgitを使用してこの問題に直面しました。また、ネットワーキングの全体的な不安定さに気づき、解決策を見つけました。

/etc/resolv.confで、ファイルの最後に行を追加します

オプションシングルリクエスト

すべてのドメイン名解決とgitがこの後魅力的に機能し始める前に、この修正された遅延。

私の問題は.netrcファイルにあることがわかりました。もしそうなら、あなたは次のことができます：

.netrcファイルを開いて編集し、github資格情報を含めます。タイプnano ~/netrcまたはgedit ~/netrc

次に、以下を含めます。* machine github.com

ログインユーザー名

パスワードSECRET

マシンapi.github.com

ログインユーザー名

パスワードSECRET *

そこに生のパスワードを含めることができますが、セキュリティ上の理由から、ここでgithubトークンで認証トークンを生成し、パスワードの代わりに貼り付けます。

これが誰かを助けることを願っています

プッシュされているコミットのサイズが原因である可能性があります。次の手順でコミット数を分析します。

git log -5

最後の5つのコミットを参照すると、リモートにプッシュされていないコミットがわかります。コミットIDを選択し、そのIDまでのすべてのコミットをプッシュします。

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

注：最大サイズになる可能性のあるコミットを確認しました。最初はそれまで押し上げました。トリックはうまくいった。

OS X El Capitan Macからgit pushを行っていました。私は同じエラーを受け取りました、私は修正するためにすべてを試しました、私がgoogle / stackoverflowで見つけたもの。バージョンに関する限り、私はgithubの最新バージョン2.7.4を使用しています。私は自分のローカルシステムにプロジェクトを作成しており、これを私のgithubアカウントで公開したいと思っていました。プロジェクトのサイズは約8MBではありませんでした。1.5MB前後のサイズのいくつかのファイルをプッシュしているとき、それは適切にプッシュしていることに気付きましたが、同じサイズで大きなサイズで失敗しました。

私が持っていた唯一のオプションは、MBのチャンクで変更をプッシュすることでした。すべての変更をプッシュしました。これは、このソリューションの修正を入手するまでの回避策です。

したがって、複数のコミットで変更をプッシュすることもできます。または、複数のフォルダーがある場合は、フォルダーごとに変更をプッシュできます（フォルダーサイズが大きくない場合）。

これがプロジェクトの継続的な作業に役立つことを願っています。

同じ問題に直面し、別のブランチとマージして、それらからプルしてみてください。同じように機能します。

のssh代わりに使用してくださいhttp、それはこの質問には良い答えではありませんが、少なくとも私にとってはうまくいきます