rsyncの"error: some files could not be transferred (code 23) at main.c(892)"でドハマリした件
超絶ハマったので情報共有。
やりたい事
既存Webサーバのドキュメントルートをスタンバイサーバにデータ同期。
リアルタイム性は要求されないのでlsyncdを使う。
症状
lsyncdが止まる(落ちる)
状態
ログに"error: some files could not be transferred (code 23) at main.c(892)"が出力されて停止している
対処
NFSマウントのカスをumount
ハマった理由
rsyncがかなり無口
エラーが起きた理由とか、このファイルがNGなどの情報が出力されなかった。
エラーコードの原因が複数あって原因が特定出来なかった。
dfコマンドの結果に問題なし
これが一番ハマった。
NFSマウントしているかどうかをdfコマンドで確認すると本番サーバでは以下の出力に。
% df
Filesystem 1K-ブロック 使用 使用可 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
552496680 74077296 449901396 15% /
/dev/sda1 101086 12581 83286 14% /boot
tmpfs 6146464 0 6146464 0% /dev/shm
192.168.1.1:/home/html/data
- - - - /home/html/data
192.168.1.1:/home/html/template
- - - - /home/html/template
192.168.1.1:/home/html/image
- - - - /home/html/image特に問題が無いように見えるけど、192.168.1.1サーバの/etc/exportsは以下の設定になっていた。
% cat etc/exports #/home/html/data 192.168.1.10(ro) #/home/html/template 192.168.1.10(ro) /home/html/image 192.168.1.10(ro)
つまり、/home/html/dataと/home/html/templateはマウント出来ない状態だったんだよ！
ΩΩΩ＜な、なんだってー！
恐らく、無効になっているマウント先をrsyncが参照してエラーを吐いて停止、という流れ。
無効になっている部分をumountしたらrsyncがちゃんと走った。
検証マシンで同じ状況を作っての結果が以下。これがきっと正常。
% df
Filesystem 1K-ブロック 使用 使用可 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
11554008 2937828 8019804 27% /
/dev/sda1 101086 25132 70735 27% /boot
tmpfs 127500 0 127500 0% /dev/shm
df: `/home/fugafuga': 実効性のないNFSファイルハンドルです
192.168.10.1:/tmp 11554016 4289984 6667680 40% /home/hogehogeちなみにmount -vの結果も同様で本番環境ではエラー出力無し。
本番環境のcoreutilsのバージョンは 5.97-23.el5、検証環境は 5.97-34.el5となっていた。
(リリースノートは見てないので違いが分からないけど)
確認重要
dfコマンドやmountコマンドの結果だけじゃなくて、lsコマンドで実際にファイルやディレクトリを確認すればすぐに発見出来た。
皆さんもコマンドの結果を信用し過ぎないようにご注意あれ。
