crontabと/etc/cron.hourly、daily、weeklyの使用の違い

Subversionリポジトリの1時間ごとのsvnsyncバックアップを行うスケジュールされたスクリプトがあります。ルートcrontabのエントリから問題なく実行していましたが、見やすくするために/etc/cron.hourlyから実行することにしました（エンジニアの1人が誤ってcrontabを削除したため、 -r」は「crontabを読む;-)）

cron.hourlyスクリプトのsvnsyncコマンドはすべて失敗し、SVNリポジトリのSSL証明書を受け入れる必要があるというメッセージが表示されます（これは、ユーザーがSVNリポジトリに初めてアクセスするときに対話形式で取得するメッセージですが、証明書がメッセージが再度表示されないことを受け入れました）。

そのため、cron.hourlyから実行する場合、root crontabを介して実行する場合とは異なるユーザー環境でスクリプトが実行されているように思えます。誰でも違いを説明できますか？

更新：私はディストリビューションについて言及すべきでした。私はCentOS 5.1でanacronを使用しています。

更新2：これまでの提案に感謝します。これはよりSubversionの質問に変わっていると思う。私は常に自分の環境をスクリプトにカプセル化しようとしますが、ここでの問題は、スクリプトを実行するときにSVNがSSL証明書の受け入れを要求する環境に何があるか（または不足している）がわからないことですcron.hourly。run-partsスクリプトの実行方法に関係していると思います。

'--config-dir'オプションを使用して、受け入れられた証明書の場所を知らせます（デフォルトでは〜/ .subversionなど）。

とはいえ、他の場所で提案されているように、代わりにhooks / post-commitスクリプトからsvnsyncを呼び出す方が良いと確信しています。その後、ミラーは、マスターが1時間前だった場所と同期するのではなく、常に同期します。

Debian / Ubuntuシステムでは、cron.daily | weekly | montlyはメインcrontabから開始されます。

17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

また、おそらく/etc/cron.d/にcrontabフラグメントを配置できることに注意してください

ご覧のとおり、この環境について特別なことは何もありません。少なくともDebian / Ubuntuでは、すべてがルートアカウントとして実行されます。

スクリプトの最初にcronスクリプトを記述するとき、使用するPATHおよびその他の環境変数を常に設定するため、どの環境でも正しく動作することを確信できます。

通常のシステム全体のcrontabは特定のユーザーのcrontabであり、によって使用されるユーザー名フィールドがあります/etc/crontab。

でスクリプトを使用して/etc/cron.*（毎時、毎日、毎週、毎月）のためのcrontabの設定のクリーンかつ容易な方法（防止共通構文エラー）でrootユーザーを、これはによって処理さrun-partsれたディレクトリ内のスクリプトやプログラムを実行します。これらのルールはすべてデフォルトでシステム全体のcrontab（/etc/crontab）で定義されているため、同じことです。

cronジョブがで処理さrun-partsれる場合、どのスクリプトが正確に実行されるか（まだ実行しない）をテストするだけで、デバッグが容易になります。

sudo run-parts --report --test /etc/cron.daily

私の最初の思いつきは、HOME変数をチェックすることです。

私のCentosシステムでは、man 5 crontabは次のように述べています。

cron（8）デーモンによっていくつかの環境変数が自動的に設定されます。SHELLは/ bin / shに設定され、LOGNAMEとHOMEはcrontabの所有者の/ etc / passwd行から設定されます。

したがって、特に指定していない場合、ルートのcrontabはHOMEに/ rootを使用します。ただし、/ etc / crontab（run-partsを介して/etc/cron.hourlyが実行される場所）では、HOMEは/に設定されます（/ bin / shではなく/ bin / bashにSHELL）。

svnsyncについては知りませんが、subversionは〜/ .subversion /ディレクトリを使用するため、HOMEに依存する可能性があります。

RHEL 5.1システムでは、PATH環境変数は/ etc / crontabから設定されます。一番上にあるものはすべて、環境に供給されるものです。

cronを再起動すると、最初に実行された場合（from /etc/crontabまたは/var/spool/cron/$USER）、/ var / log / cronに記録されます。それ以外の場合は、cron.hourlyが実行されたことに注意します。

私のcrontabは次のように設定されています：

01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

できることは、次のようなものを/etc/cron.hourlyに入れることです。

env > /tmp/cron.env

その後、ファイルを調べて環境を適切に設定するためにスクリプトを変更します（可能な場合）、またはcrontabが呼び出す短いラッパースクリプトを記述します。

/var/log/messages （または同等のディストリビューション）は、どのコマンドがいつ、どのユーザーとして実行されたかの詳細を伝える必要があります。

環境に何かがあると思い込まないでください。常に防御的にコーディングします。あなたはそこにあなたが望むものをセットアップするどんな環境でも置くためのファイル全体を持っています。これを使って。

他の移植性はあまりありませんが、前回（Debianで）チェックしたときには、cron.hourly（およびその他）にアイテムを入れることをお勧めしました。