この前設定したlsyncdですが、いつの間にか勝手に止まってました。なぜだろう?と思いログを見てみると下記のようなエラーで止まっていた。
rsync: failed to connect to 192.168.1.2: Connection refused (111) rsync error: error in socket IO (code 10) at clientserver.c(107) [sender=2.6.8] Sun Aug 9 04:02:11 2009: Forked binary process returned non-zero return code: 10 Sun Aug 9 04:02:11 2009: ERROR: Initial rsync from /home/www/vhosts/ to 192.168.1.2::www failed.
どうやら転送先に接続できなくて強制終了しているみたい。転送先では正常にrsyncdは起動していました。気になったのは時間です。4時2分?ログローテートの際にrsyncdを再起動しているため偶然止まったのかな・・・?
色々調べてみると、「rsyncで転送中に転送先と通信ができなくなったときに強制終了する」ということがわかりました。しかし、一回接続出来なかったくらいで勝手に止まっても困るところです。
どんな処理しているのかソースコードを眺めていると下記の記述を発見しました。
/** * Global Option: if true, ignore rsync errors on startup. * (during normal operations they have to be ignored eitherway, * since rsync may also fail due e.g. the directory already * beeing deleted when lsyncd wants to sync it.) */ int flag_stubborn = 0;
どうやらオプションで、stubbornというオプションがあるらしい。こいつを設定すれば勝手に止まるようなことがなくなるかも?試しに設定して実験してみることに。
## /usr/local/etc/lsyncd.conf.xml を編集 <settings> # グローバルオプションなので、settings要素の間に記述する <stubborn/> # これを追加する </settings>
適当に1Gほどの空ファイルを作成し、lsyncdで同期中に転送先のrsyncdを止めてみました。エラーは出力されますが、強制終了することなく動いているようです。rsyncdを動かすと、再度転送が始まるのかと思いきや、転送はされませんでした。さらに適当なファイルを作成してみたところ、前回中途半端だった転送途中のファイルも含めて、しっかり転送されることを確認。転送途中のファイル転送が再開されないのがちょっと予定外でしたが、とりあえずこれで大丈夫そうです。
## ddで空のファイルを作成 $ dd if=/dev/zero of=blank bs=1024 count=1000000