転送中にrsyncが突然無期限にハングする
過去数年間、rsyncワンライナーを使用して、Mac Miniデスクトップ（OSX 10.9、2.5 GHz i5、4 GB RAM）の重要なフォルダーをFreeNASボックス（0.7.2 Sabandaリビジョン5266、Pentium）にバックアップしましたD 2.66 GHz、822MiB RAM [システムによって報告され、そこに1 GBがあると思います]）。FreeNASボックスでrsyncデーモンを実行しています。最近、これらの転送は無期限に停止しています。 。通常のGoogle-fuを実行しましたが、問題の原因または解決策を特定できません。
ワンライナーは次のとおりです。
rsync -rvOlt --exclude '.DS_Store' \
--exclude '.com.Apple.timemachine.supported' \
--delete /Volumes/Storage/Music/Albums/ 192.168.1.100::albums
-vvvと--progressを有効にしようとしましたが、ハングするものとしないものを区別できるパターンはありません。ちなみに、再試行すると、同じファイルが転送中の異なるポイントでハングするか、まったくハングしない可能性があります。ドライラン（-n）も常に成功するとは限りません。私が経験した唯一の「成功」は、タイムアウト（--timeout=10）を実装し、何度もコマンドを再実行することです。最終的に、私は忍び寄るが、成功を保証するものではなく、受け入れられないペースである。私は、私がすり抜けることができない1つのファイルを持っているポイントに達しました。
Mac Miniは5 GHzを介してルーターに接続されています。 FreeNASボックスは、100 mbitポートで同じルーターに配線されています。転送が実際に行われているとき、rsync --progressは2.5-4 MB/sを報告します。 --progressによれば、ハングとは文字通りそれだけです。私が知る限り、データ転送は発生していません。
診断と解決策の両方について支援が必要です。
私は同じことを何度も繰り返してきましたが、-vオプションをドロップすると役立つようです（その出力が必要な場合は迷惑です）。
これは、リモートデバイスのスペースがなくなったときに起こりました。 --verboseオプションが使用された場合、エラーは表示されません。これをオフにすると、リモートデバイスのスペース不足を説明するSTDERR出力が生成されました。いくつかのスペースを解放すると、--verboseを使用してrsyncを再度実行でき、すべてがうまくいきました。
私は同じ問題を抱えていました。 -vを削除してもうまくいきませんでした。私のユースケースは、ソース（EXT4）からExFATに移行するという点でわずかに異なります。私にとっての問題は、rsyncがデバイスファイルとアクセス許可を保持しようとしたことでしたが、ExFATはサポートしていません。 _-hrltDvaP_スイッチを使用していました。 _-D_および_-a_スイッチは私の問題のようです。 _-a_スイッチは-rlptgoD (no -H,-A,-X)に変換されます。 _-p_、_-g_、および_-o_スイッチは、rsyncが実行中にそれらの1つまたはすべてを妨害しているため、私の根本原因であると思われました。 _-a_を削除し、_-Prltvc_スイッチを明示的に指定することは、私にとってはうまくいきます。
_bkupcmd="Nice -n$nicelevel /usr/bin/rsync -Prltvc --exclude-from=/var/tmp/ignorelist "
_私はopenSUSE 13.2 Linux、rsyncバージョン3.1.1-2.4.1.x86_64を使用していますが、ラップトップと外部ハードディスクの間でrsyncを実行すると同様の問題が発生し、宛先デバイスには十分な空き容量があります。
オプション-vを省略して改善したと思いましたが、10分後に再びハングしました：straceが言いました：select（5、[]、[4]、[]、{60、0}）= 0（タイムアウト）
また、「iotop」を使用すると、rsyncプロセスで重要なディスクがなかったことを確認できますIOもう。
-vオプションを削除することも、-bwlimitを使用して帯域幅を制限することも、問題を解決しませんでした。
ハードディスクからFAT32 USBドライブへのrsyncの実行中に同様の問題が発生しました。私の場合、rsyncはすでに1秒未満でフリーズしましたが、その後はまったく反応しませんでした... CTRL + Cで残しました。
問題は、ハードディスク上のハードリンクの使用と、ハードリンクをサポートしていないUSBドライブ上のFAT32ファイルシステムの組み合わせであることがわかりました。
ext4でUSBドライブをフォーマットする 私のために問題を解決しました。
私の状況では、rsyncは実際には失敗していませんでした。
500GB以上の大きなファイルを転送する定期的なサーバーバックアップがあり、sshパラメーターで_--append-verify_または_--checkusm_が指定されています。
分析の結果、クライアント側がファイルチェックを完了すると、サーバー側のチェックが開始されることがわかりました。これは、サーバーの実行中にクライアント側をチェックすることを意味しますハングしてフリーズしたように見えます-rsyncを実行するためにサーバーでhtopを実行します。
サーバー上でrsyncがデーモンモードで実行され、転送にrsyncの代わりにsshプロトコルを使用している場合、これはおそらく問題ではありません。
関連する注意事項として、この非常に長い待機はSSHタイムアウトとrsync: connection unexpectedly closed (254 bytes received so far) [sender]エラーメッセージをトリガーし、解決策は_ClientAliveInterval 120_と_ClientAliveCountMax 720_を_/etc/ssh/sshd_config_に追加することです。
私は同じ問題を抱えていましたが、それはrsync中にメモリが不足していたためです。スワップファイルを作成し、問題を解決しました。
Ubuntu 16でrsyncがハングする問題がありました。上記のオプションはどれも役に立ちませんでした。問題はソースドライブ（外部SSD）にあり、突然故障しました。いくつかのディスクチェックを試しましたが、すべてが停止しました。システムを再起動し、ディスクが突然再びアクセス可能になりました。
また、ターゲットマシンのユーザーがターゲットフォルダーへの書き込み権限を持っていない場合にも発生します。
他のターゲットフォルダーに書き込み権限を付与してみることができます。
Sudo chmod -R o+w /path/to/target-folder
「あなた」の問題ではない可能性が高いのですが、同様の動作を調査していたときにこの問題に出くわしました。
ターゲットサイトのio負荷が大きすぎると、「ハング」します。例えば。私のスモールビジネスサーバーの1つで、誰かが自分のIMAPアカウントを再同期し、大量のデータをダウンロードし、データを書き込むバックアップジョブを実行したとき。
この状況では、rsyncのパフォーマンスが急激に低下することに気付きます。 CPUとMemは問題ありませんが、ターゲットマシンのtopの高負荷値で顕著です。
プロセスが完了するのを待つことは、毎回、または後で中断してrsyncを再試行するのに役立ちました。