なんてこと?! cron ジョブが実行されない?!
実行されていない cronjobs をデバッグするためのチェックリスト ガイドは次のとおりです:
<オール>ps ax | grep cronを実行 cron を探します。- Debian:
service cron startまたはservice cron restart
- cron は機能していますか?
* * * * * /bin/echo "cron works" >> /tmp/file- 構文は正しいですか?以下を参照してください。
- 出力をリダイレクトするファイルへの書き込みアクセス権が必要であることは明らかです。
/tmpの一意のファイル名 現在存在しないものは、常に書き込み可能である必要があります。 - おそらく
2>&1も追加します 標準出力と同様に標準エラーを含めるか、標準エラーを別のファイルに2>>/tmp/errorsで個別に出力します
- コマンドはスタンドアロンで動作していますか?
- CLI で予行演習を実行して、スクリプトにエラーがないかどうかを確認します
- コマンドをテストするときは、編集している crontab のユーザーとしてテストします。これは、ログインまたはルートではない可能性があります
- cron でジョブを実行できますか?
/var/log/cron.logをチェック または/var/log/messagesエラーについて- Ubuntu:
grep CRON /var/log/syslog - Redhat:
/var/log/cron
- 権限を確認する
- コマンドに実行可能フラグを設定します:
chmod +x /var/www/app/cron/do-stuff.php - コマンドの出力をファイルにリダイレクトする場合は、そのファイル/ディレクトリへの書き込み権限があることを確認してください
- パスを確認
- she-bangs / hashbangs ラインをチェック
PATHのような環境変数に依存しない 、それらの値は、対話型セッションの下と cron の下で同じではない可能性が高いためです。正しい PATH で CRON を呼び出す方法を参照してください
- デバッグ中に出力を抑制しない
- 一般的に使用されるのは、次の抑制です:
30 1 * * * command > /dev/null 2>&1 >/dev/null 2>&1を削除して、標準出力または標準エラー メッセージ出力を再度有効にします 完全に;または、書き込みアクセス権のある場所にあるファイルにリダイレクトすることもできます:>>cron.out 2>&1標準出力と標準エラーをcron.outに追加します 呼び出し元ユーザーのホーム ディレクトリ内。cronからの出力をリダイレクトしない場合 ジョブを実行すると、デーモンは出力またはエラー メッセージを電子メールで送信しようとします。受信トレイを確認してください (単純にmore $MAILかもしれません) メール クライアントがない場合)。メールが利用できない場合は、dead.letterという名前のファイルを確認してください ホームディレクトリ、または出力が破棄されたことを示すシステムログエントリ。特に後者の場合は、おそらくジョブを編集してファイルにリダイレクトを追加し、ジョブが実行されるのを待ち、エラー メッセージやその他の有用なフィードバックがないかログ ファイルを調べます。- 何かが失敗した理由を理解しようとしている場合は、このファイルにエラー メッセージが表示されます。読んで理解してください。
まだ動作していませんか?いいね！
<オール>- Debian
- in
/etc/default/cron - set
EXTRA_OPTS="-L 2" service cron restarttail -f /var/log/syslog実行されたスクリプトを見る
- in
- Ubuntu
- in
/etc/rsyslog.d/50-default.conf - 行
cron.* /var/log/cron.logを追加またはコメントアウトします - ロガーをリロード
sudo /etc/init.d/rsyslog restart - cron を再実行
/var/log/cron.logを開く 詳細なエラー出力を探します
- in
- 注意:デバッグが完了したら、ログ レベルを無効にしてください
- cron を実行してログ ファイルを再度確認する
Cronjob 構文
# Minute Hour Day of Month Month Day of Week User Command
# (0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat)
0 2 * * * root /usr/bin/find
この構文はのみです root の場合は正しい ユーザー。一般ユーザー crontab 構文に User がありません フィールド (通常のユーザーは他のユーザーとしてコードを実行することはできません);
# Minute Hour Day of Month Month Day of Week Command
# (0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat)
0 2 * * * /usr/bin/find
Crontab コマンド
<オール>crontab -l - ユーザーのすべての cron タスクを一覧表示します。
crontab -e 、特定のユーザーの場合:crontab -e -u agentsmith - crontab ファイルの編集セッションを開始します。
- エディタを終了すると、変更された crontab が自動的にインストールされます。
crontab -r - crontab ファイルからではなく、cron スプーラから crontab エントリを削除します。
私が学んだ 2 つのポイントを追加したいと思います:
<オール>参照:
<オール>最後に、解決策を見つけました。以下が解決策です:-
<オール>crontab 経由で実行される Python スクリプトで相対パスを使用しないでください。代わりに、次のようなことを行いました:-
import os
import sys
import time, datetime
CLASS_PATH = '/srv/www/live/mainapp/classes'
SETTINGS_PATH = '/srv/www/live/foodtrade'
sys.path.insert(0, CLASS_PATH)
sys.path.insert(1,SETTINGS_PATH)
import other_py_files
代わりにメールサーバーを使用して、ユーザーのメールを確認して、crontab コードを抑制しないでください。これにより、何が起こっているかについてより明確な洞察が得られます。
crontab が失敗するもう 1 つの理由:% の特別な処理
マニュアル ファイルから:
The entire command portion of the line, up to a newline or a
"%" character, will be executed by /bin/sh or by the shell specified
in the SHELL variable of the cronfile. A "%" character in the
command, unless escaped with a backslash (\), will be changed into
newline characters, and all data after the first % will be sent to
the command as standard input.
私の特定のケースでは、 date --date="7 days ago" "+%Y-%m-%d" を使用していました スクリプトにパラメーターを生成するために、サイレントに失敗していました。 syslog を確認したところ、ようやく何が起こっているのかわかりました 私のコマンドが % で切り捨てられているのを見ました シンボル。次のようにエスケープする必要があります:
date --date="7 days ago" "+\%Y-\%m-\%d"
詳細はこちらをご覧ください:
http://www.ducea.com/2008/11/12/using-the-character-in-crontab-entries/