私が働いているところでは、Debian Wheezyを実行する中央バックアップサーバーがあり、各サイトにDebian Wheezyを実行しているオンサイトサーバーがあります。
数週間前、中央オフィスの技術者が私に電子メールを送り、前日の夜のバックアップが正しく完了していないと言いました。それ以来、問題を解決してきましたが、まだ問題を解決できないようです。唯一の反論は、cron
電子メールで次のとおりです。
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(549) [generator=3.0.9]
rsync error: received SIGUSR1 (code 19) at main.c(1316) [receiver=3.0.9]
このフレーズをインターネットで検索してみると、ほとんど何も出ません。削除スイッチの2002年の投稿を見つけ-v
ましたが、スクリプトでは使用されません。毎晩実行されるスクリプトは次のとおりです。
#!/bin/sh
set -e
x="delete --exclude-from=r_filter --delete-excluded"
rsync -aq --$x site1.company.com:/etc /BACKUPS/site1
rsync -aq --$x site1.company.com:/home /BACKUPS/site1
月曜日から金曜日まで午前3時に中央バックアップサーバーで実行するように設定されています。日中に手動で実行しようとすると正常に動作します(ほとんどのファイルが以前にバックアップされたためですか?)。スイッチを使用しているので、-a
開いているファイルを保持できると思いますか?それが私が考えることができるすべてです。
この問題を解決するための次のステップは何ですか?
答え1
テストのために1分以内にジョブを実行したときに発生しない特定の時間にcrontabでジョブを実行したときに発生する場合は、2つの可能性があります。
- crontabには何らかの方法でプロセスを妨げる別のプロセスがあります。
- 掃除員が掃除機を接続するためにコンピュータのプラグを抜くように、人間のプロセスが進行していました。
rsync プロセスは、夜のある時点で信号を受信します。私が最初に見つけなければならないのは、crontabの他のプロセスが送信しない信号を送信するかどうかです。
(コマンドラインで実行するとうまく機能しますが、cronで実行すると失敗する場合は、これは全く違う魚鍋です。.)
答え2
このようなことが再発生しないように、コマンドが信号の影響を受けないようにするのと同時に、同じプロセスグループの一部の親プロセスを介してシェルに渡される場合は、バックグラウンドで信号をキャプチャできます。たとえば、
#!/bin/bash
( trap 'echo got signal; date; ps ax; kill $pid; exit' sigint sigterm sighup
sleep 999999 &
pid=$!
wait
) &
trap '' sigint sigterm sighup
rsync ...
rsync ...
kill -hup $!
trap ''
次のコマンドにリストされている3つの信号は無視されます。の背景部分は、()
信号をキャプチャし、たとえばps
その瞬間に実行中の項目を見つけるのと同様の操作を実行します。
logrotate
私はこれを知らせる過度に情熱的な命令のような愚かなものを見つけるでしょう。