私はrsync
何年も使ってきましたが、このような奇妙な問題が発生したことはありません。リモートシステムがLinux Mint 20を実行している場合を除いて、すべてがうまく動作します(そのうちの2つを試しましたが、1つはまだ20.1を実行し、もう1つは20.2を新しくインストールしました)。単一ファイルであるか、ディレクトリ全体であるか、単純なリソースのリストであるかにかかわらrsync
ず、ネゴシエーションの直後に中断されます(「プッシュ」または「プール」のいずれに関係なく)。リモコンがDebian、Armbian、Mint 18の場合でも、同じコマンドが正常に動作します(今すぐ確認するために古いノートブックを開いています)。簡単なことでも
rsync remote:/path/to/file .
歩く。利用可能なデバッグオプションを試した結果、(SSHキーまたはパスワードを介して)認証が正しく行われていることがわかりました。間違ったパスワードを入力すると、正しい「終了」が表示されます。ただし、正しいパスワード/キーを提供すると、認証直後にセッションが中断され、手がかりは提供されなくなります。私が最後に見たのはexec request accepted
。ps
リモートシステムで使用すると、そのプロセスがrsync
作成されたことがわかります(たとえば、尋ねる前に:SSHを介してシステムに接続すると正常に動作し、期待どおりにscp
動作しますが、そうではありませんrsync
)。
最後の手段と解決策として、リモートrsyncd
システムで一時的な作業を開始しました。
rsync --config=/tmp/rsyncd.conf --daemon --no-detach
それからrsync remote::share/path/to/file
。これがうまくいき、現在のタスクが完了している間に何かを同期する必要があるたびにこのタスクを繰り返すことはしたくありません。
編集する:
リモートの一部の出力.bashrc
が介入できると仮定できます。 (ssh remotehost /bin/true > out.dat
マンページで確認を提案したように)0バイトのファイルが生成されるため、これが原因ではありません。
strace
リモートで作成された3つのプロセスを実行するとrsync
(すべて同じコマンドラインがあります。1つは先行し、残りの2つはありません)、期待どおりに「クライアント」(ユーザーが呼び出す)bash
で終わることがわかります。リモート側の応答を待っている可能性が高いため、1を表示します。wait4(-1,
{tv_sec=32, tv_usec=23154}
rsync
wait4(-1,
原因が何であるか、それを解決する方法についてのアイデアがありますか?どのように絞り込むことができますか?デバッグについては私が使ったことがありますrsync --debug=all4 -avve "ssh -vvv" …
が、こう説明しました。
参考までに、rsyncd.conf
上記の回避策は次のとおりです。
chroot=true を使用 ホストを許可 = 192.168.0.0/24 送信ロギング = true ログファイル = /tmp/rsyncd.log ログ形式 = %h %o %f %l %b [共有する] コメント=共有 パス=/mnt/share 読み取り専用=いいえ リスト=はい uid=誰もなし gid =グループなし
答え1
3番目のMint20システムを使用して問題を再現できなかった後、犯人を見つけました。これは、Mint20システムの1つが「サーバー」として参加して検索を絞り込んだ場合にのみ発生することがわかりました。which rsync
そこに走って/usr/local/bin/rsync
帰ってきました。これは(「サーバー」側に表示された4番目のrsyncプロセスと一緒に、定期的に実行している他のプロセスに属すると思ったので無視しました)、次のように進めました。
/usr/local/bin/rsync
職業を中心に整理される同期エラーこの問題は2006年から知られており、まだ修正されていません。スクリプトはここにあります)。マシンはクライアントとしてのみ使用されているため、この厄介な問題を解決するために長年にわたってうまく機能していましたが、マシンを交換し、転送のためにサーバーとして機能する必要があるため、非生産的です。
現在の問題だけでなく、元の問題を解決するためにスクリプトをアクティブPATH
なユーザーのディレクトリにのみ移動しましたが、いいえ root
(リモコンはrsync
常にルートによって作成され、オリジナルをインポートする必要があります/usr/bin/rsync
)。すべての方向でテストした後に動作するようです(元の回避策を適用した「対応するcronジョブ」を待つだけです)。
PS:rsync-no-vanished
このスクリプトを使用している場合は、わずかに調整して問題を解決します。スクリプトを次のように変更します。
if [[ $(id -u) -eq 0 ]]; then
/usr/bin/rsync $@
else
# original "rsync-no-vanished" script in here
fi
これにより、ルート(たとえば、生成されたリモート)から呼び出されたときに元のrsync
バイナリのみが参照され、クライアントによって呼び出された「解決方法」のみが使用されます。
添付:詳細と提案された修正でプロジェクトに連絡した後、スクリプトまもなく更新されますこれにより、今後同様の状況を避けることができます(すぐに答えてくれたWayneに感謝します!)。