crontabと/etc/cron.hourly、daily、weeklyの違い
Subversionリポジトリの1時間ごとのsvnsyncバックアップを実行するスケジュールされたスクリプトがあります。ルートcrontabのエントリから問題なく実行していましたが、可視性を高めるために/etc/cron.hourlyから実行することを決定しました（エンジニアの1人がcrontabを誤って削除したため、「crontab -rは「crontabを読む;-)）を意味します
Cron.hourlyスクリプトのsvnsyncコマンドはすべて失敗し、SVNリポジトリのSSL証明書を受け入れる必要があることを示すメッセージが表示されます（これは、ユーザーが初めてSVNリポジトリにアクセスしたときにインタラクティブに表示されるメッセージですが、証明書が受け入れられたメッセージは再び表示されません）。
そのため、スクリプトは、cron.hourlyから実行した場合と、ルートcrontabから実行した場合とでは、異なるユーザー環境で実行されているように見えます。誰でも違いを説明できますか？
更新：私は私のディストリビューションについて言及するべきでした、私はCentOS 5.1でanacronを使用しています。
更新2：これまでの提案に感謝します。これは、Subversionに関する質問になりつつあると思います。私は常に自分の環境をスクリプトにカプセル化しようとしますが、ここでの問題は、スクリプトを実行したときにSVNがSSL証明書の受け入れを要求する環境が何であるか（または欠けている）環境がわからないことですcron.hourly。 run-partsスクリプトの実行方法に関係しているのではないかと思います。
'--config-dir'オプションを使用して、承認された証明書の場所を通知します（たとえば、デフォルトでは〜/ .Subversion）。
そうは言っても、フック/ポストコミットスクリプトから 他の場所で推奨 のように、代わりに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では、すべてがrootアカウントとして実行されます。
スクリプトの最初でcronスクリプトを作成するときは、常にPATHと使用する他の環境変数を設定しているので、どの環境でも正しく機能することを確認できます。
通常のシステム全体のcrontabは特定のユーザーのcrontabであり、/etc/crontabで使用されるユーザー名フィールドがあります。
/etc/cron.*でスクリプトを使用する（毎時、毎日、毎週、毎月）は、rootユーザーのcrontabを構成するためのより明確で簡単な方法（一般的な構文エラーを防止）であり、これはrun-partsによって処理されますディレクトリでスクリプトまたはプログラムを実行します。これらすべてのルールは、デフォルトでシステム全体のcrontab（/etc/crontab）で引き続き定義されているため、同じです。
Cronジョブがrun-partsによって処理されると、次の方法で（まだ実行されていない）正確に実行されるスクリプトを簡単にテストできるため、デバッグが容易になります。
Sudo run-parts --report --test /etc/cron.daily
私の最初のワイルドな推測は、HOME変数を確認することです。
私のCentosシステムでは、man 5 crontabはこう言っています：
いくつかの環境変数は、cron（8）デーモンによって自動的に設定されます。シェルは/ bin/shに設定され、LOGNAMEおよびHOMEはcrontabの所有者の/ etc/passwd行から設定されます。
したがって、特に指定しない場合、rootのcrontabはHOMEに/ rootを使用します。しかし、/ etc/crontab（run-partsを介して/etc/cron.hourlyが実行される場所）では、HOMEは/（および/ bin/shの代わりに/ bin/bashへのシェル）に設定されます。
Svnsyncについては知りませんが、Subversionは〜/ .Subversion /ディレクトリを使用するため、HOMEに依存する可能性があります。
私のRHEL 5.1システムでは、PATH環境変数は/ etc/crontabから設定されます。一番上にあるものはすべて、環境に供給されるものです。
Cronを再起動すると、最初に実行されたときに（/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が呼び出す短いラッパースクリプトを記述します。
他にそれほど多くの移植性はありませんでしたが、前回（Debianで）チェックしたときは、ものを含むパッケージを作成する場合は、cron.hourly（およびその他）にものを置き、直接crontabに入れないことをお勧めしました。
/var/log/messages（またはディストリビューションの同等物）は、どのコマンドがいつどのユーザーとして実行されたかの詳細を通知します。
環境に何かがあると思い込まないでください。常に防御的にコーディングしてください。あなたはそこにあなたが望むものをセットアップするあらゆる環境を置くためのファイル全体を持っています。これを使って。