web-dev-qa-db-ja.com

SVNリポジトリから更新すると、「Could not read chunk size」エラーが返されます

Tortoise svnクライアントを使用してSubversionリポジトリから更新すると、次のようなエラーが表示されます。

Could not read chunk size: An existing connection was forcibly closed by the remote Host.

更新が妨げられることはなく、更新プロセスを中断するだけなので、更新が完了する前に更新を数回繰り返す必要があります。

そのような動作の原因とその修正方法は何ですか？

svntortoisesvnconnection
55
Denis

複数のマシン上のクライアントから「チャンクサイズを読み取れませんでした」というメッセージが表示されていました。

それを理解する鍵は、Apacheエラーログにある次のエラーです。

[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Provider encountered an error while streaming a REPORT response.  [500, #0]
[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Problem replaying revision  [500, #24]
[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Can't open file '/usr/site/svnrep/impc/db/revs/16122': Too many open files  [500, #24]

Svn操作を処理するApacheプロセスがファイル記述子を使い果たしていました。私のUbuntuサーバーでは、/etc/security/limits.confを編集し、これを下部に追加することで修正しました。

*               hard    nofile          5000
*               soft    nofile          5000

これにより、ファイル記述子の制限が1024から5000に増加します。その後、新しいシェルにログインし、ulimit -nを介して制限が増加することを確認しました。その後、Apacheを再起動しました。

15
Lachlan

「チャンクサイズを読み取れませんでした」というエラーが表示されました ソリューションを見つけました -少なくとも1つのシナリオ。

最初に、私の構成...

サーバ： Windows Server 2003 32ビットで実行されているCollabNet Subversion Edge Server 2.0.0-2190.74（Subversionバイナリ1.6.17-2190.74）。

クライアント： TortoiseSVN 1.6.16、ビルド21511-Windowsで実行されている32ビット（Subversion 1.6.17）XP Pro 32ビットSP3。

再現する手順...

バージョン管理されたサブフォルダーをローカルの作業コピーフォルダー内の別のバージョン管理されたサブフォルダーに右クリックしてドラッグしてからこのエラーを取得しました 「SVNバージョン管理されたアイテムをここにコピー」 （これは、フォルダーを右ドラッグするときのWindowsエクスプローラーのTortoiseSVNコンテキストメニューコマンドです）。サブフォルダーには、ANSIエンコードされた1つのMANIFEST.MFテキストファイルが含まれていましたが、これは変更しなかったと思います（私のSubversion構成には.MFファイルのMIMEタイプが含まれていません）。 その後、新しくコピーしたサブフォルダーをコミットしました。 後で、このPC上のSubversionローカル作業コピーフォルダーを更新しようとすると、チャンクサイズエラーが発生しました。

回避策...

Subversion/Apacheサービスを再起動することでこれを解決しました（それ自体は役に立たず、必要なかったかもしれません）。 ローカルの作業コピーフォルダーから新しく追加されたサブフォルダーを削除する （すでにレポに到達しているため、何も失うことはありませんでした）、 そして、更新を実行します、チャンクサイズエラーなしで成功し、削除したサブフォルダーを再取得しました。

私の場合、この方法で2つのバージョンのサブフォルダーをコピーしたため、これらの新しいサブフォルダーの両方を削除するまで、ローカルの作業コピーフォルダーのルートを正常に更新できませんでした。

ファローアップ...

これはSubversionサーバーやTortoiseSVNクライアントのバグだと思いますが、その判断を下すためのデバッグスキルはありません。 TortoiseSVN Issue Trackerで私の調査結果を報告し、それがどこに行くかを確認します。

11
MikeOnline

私はちょうどこれが私に起こったのですが、それはnotサーバーの問題でした。作業コピーが破損しました（偶然）。

10
hoffmanc

クライアント側のウイルス対策をオフにすると、問題と（その他の）問題はなくなりました。

Subversion 1.7.4でUbuntuサーバーをApache経由で使用しています。

7
vrogach

Apacheエラーログを確認してください。エラー番号とともにエラーが記録されているはずです。その数値は、接続が切断された理由を見つけるのに役立ちます。

エラーログに何もない場合は、ウイルススキャナー/ファイアウォールの設定を確認してください。これらのツールの一部は、転送されたデータが危険だと判断した場合に接続を切断します。

3
Stefan

私たちにとって問題は、Apacheのタイムアウトでした。更新には約15分かかりましたが、Apacheは10分後にタイムアウトになり、SVNサーバーが表示されたエラーを出しました。最終的な解決策は、Apacheのタイムアウト設定を増やすことでした。 VisualSVNサーバーを使用します-この設定を変更する方法の詳細については、こちらをご覧ください： http://adventuresindotnet.blogspot.com/2010/09/svn-trouble.html

2
CodeThug

フォルダーの名前を変更してコミットした後、更新時に同じエラーメッセージが表示されました。新しい作業ディレクトリを作成しましたが、エラーは表示されませんでした。そのため、変更を新しい作業ディレクトリに移動し、コミットして古いディレクトリを削除しました。

そのため、このエラーはローカルディレクトリが破損していることが原因のようです。

1
user1097928

Ubuntuサーバーに変更したところ、同じエラーが発生しました-複数のクライアントPC、OS、およびクライアントバージョン間で。

ファイル制限設定とApacheタイムアウト設定の両方が推奨どおりであることを確認した後。

（ http://posidev.com/blog/2009/06/04/set-ulimit-parameters-on-ubuntu/ を参照）

最終的に、Apache2-mpm-workerパッケージではなくApache2-mpm-preforkパッケージを使用して問題を解決しました。

1
Simon Hoffe

それもわかった。私たちのサーバーは、Windows上で実行されるApacheです。私のクライアントは高速で接続されていますが、待ち時間が多少長くなっています（200ミリ秒）。パズルの他の部分は、Windows Vistaを実行していることです。自動スケーリングとrssを有効にすると状況は改善されるようですが、それは修正されません。

0
Jeremy White

このエラーメッセージには別の迷惑な原因があります。ルーターまたはルーターのファームウェアである可能性があります。

最近、Linksys WRT110のファームウェアをバージョン1.0.02から1.0.07にアップグレードした後、Subversionはリポジトリに新しいファイルを追加できなくなりました。既存のファイルのみを更新できました。 1.0.02にロールバックすると、問題が修正されました。

ソース：

基本的に、接続が突然切断されるたびに、このエラーが発生します。あなたの多くが述べたように、Apacheの設定エラーである可能性があります。また、サーバーの速度が遅いか、接続が過負荷である可能性もあります。または、私の場合のように、安価なルーターが原因の可能性もあります。

0
mrbinky3000

私たちにとって、回避策はdowngrade the SVN client from 1.8 to 1.7（TortoiseSVNにバンドルされているコマンドラインクライアント）です。

0
Frank Schmitt

これには明らかに多くの原因がありますが、私にとっては、SVNサーバー（VisualSVNServer 2.5.1）を再起動することで修正されました。これは、新しくロードされたダンプで完全なレポチェックアウトを行うときに頻繁に発生します。

0
Derrick

VisualSVN 2.5.8：同じエラーが発生したため、次の手順でこのエラーを修正できました。

サーバー上：

  1. サーバーの問題のあるフォルダーで削除されました。
  2. VisualSVNサーバーを再起動します。

ワークステーション上：

  1. 親フォルダーを更新します。
  2. フォルダーとファイルを再度追加します。
  3. SVNに追加します。
  4. コミット。
0
Eugene Bosikov