私は多くの一般的なエラーを取り除こうとしましたが、
cronでPATHが利用可能であることを確認してください。
crontabファイルの最後に閉じる行があります。
タイムゾーンは次のように設定されます。
cd /etc cp /usr/share/zoneinfo/Asia/Singapore /etc/localtime
Bashで実行すると、date次のようになります。
Tue Sep 17 15:14:30 SGT 2013
cronが同じ時間を使用していることを確認するには、
* * * * * date >> date.txt
date.txt に同じ日付出力を提供します。
これは私が実行したいスクリプトです。
event.sh:
#!/usr/bin/env bash
echo data > /root/data.txt
を使用すると、crontab -e次の行が機能します。
* * * * * /bin/bash /root/event.sh >/tmp/debug.log 2>&1
15 * * * * /bin/bash /root/event.sh >/tmp/debug.log 2>&1
ただし、他のパラメータを試すときは午後2時50分に実行したいと思います。
50 14 * * * /bin/bash /root/event.sh >/tmp/debug.log 2>&1
または
50 14 * * * (cd /root ; ./event.sh >/tmp/debug.log 2>&1)
もう動作しません。私のタイミングの主張に問題があるようです。ファイルには何も見つかりませんでした/tmp/debug.log。
解決策：
その結果、TZを変更した後にcronサービスを再起動する必要がありました。
答え1
まず、1つのフィールドを考慮する際にエラーを引き起こすバグが発生する可能性は次のとおりです。異常に低い。これは何が起こっているのか、そしてクローンが期待していることに対する誤解である可能性が高いです。
この場合、私たちは質問へのコメントを通して、これが時間帯関連の問題である可能性が最も高いことを発見しました。これを行うには、次のようにします。
* * * * * datecrontabに類似- 削除する（またはコメントアウト）crontabのすべてのTZ割り当て
これにより、date実行時に呼び出し元のタイムゾーン設定が使用されます。これはcronデーモンです。出力を見ると、cronが内部的に使用するタイムゾーンが表示されるため、時間フィールドがどのタイムゾーンにあるかを望む可能性が高くなります。 crontabにTZ割り当てがある場合、TZ環境変数の割り当ては呼び出しコマンドに簡単に渡されます。しかし、cron自体は異なるタイムゾーンを使用します。。 TZ 割り当てにコメントを付けたり削除したりすると、このあいまいさを回避できます。
さらに、システムのグローバルタイムゾーン設定（/ etc / localtimeを含む）を変更するには、少なくともcronデーモンを再起動する必要があります。 crontabでTZ割り当てを編集するしてはいけないcronデーモンはファイルが変更されたことを検出し、自動的に再ロードする必要があるため、再ロードする必要があります。