多くの場合, crontab スクリプトは、スケジュールどおりに、または期待どおりに実行されません。 そのための多くの理由があります:
このコミュニティwikiは、以下の主な理由を集約することを目的としています crontab スクリプトが期待どおりに実行されません。 それぞれの理由を別々の答えに書いてください。
回答ごとに1つの理由（実行されない理由の詳細）を含め、その1つの理由で修正してください。
シェルから期待どおりに実行されるが、cronによって誤って実行されるコマンドなど、cron固有の問題のみを記述してください。
異なる環境
Cronは、最小限の環境変数セットをジョブに渡します。 違いを確認するには、次のようなダミーのジョブを追加します:
>*****env/tmp/env。出力
待って /tmp/env.output 作成するには、ジョブを再度削除します。 今の内容を比較します /tmp/env.output の出力を使って env 通常の端末で実行します。
ここでの一般的な"gotcha"は次のとおりです PATH 環境変数が異なる。 たぶんあなたのcronスクリプトは次のコマンドを使用します somecommand で見つかった /opt/someApp/bin あなたが追加した、 PATH で /etc/environment? cronは無視します PATH そのファイルから、だからrunnning somecommand あなたのスクリプトからは、cronで実行すると失敗しますが、端末で実行すると動作します。 それは注目に値する変数から /etc/environment cronジョブに渡されますが、cronが具体的に設定する変数だけではなく、次のようになります PATH.
それを回避するには、独自の設定を行うだけです PATH スクリプトの先頭にある変数。 例えば
#!/bin/bashPATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin# rest of script follows一部の人は、代わりにすべてのコマンドへの絶対パスを使用することを好む人もいます。 私はそれに対してお勧めします。 別のシステムでスクリプトを実行したい場合、そのシステムでは、コマンドは次のようになります /opt/someAppv2.2/bin 代わりに。 あなたは全体のスクリプトを通過する必要があります交換 /opt/someApp/bin と /opt/someAppv2.2/bin スクリプトの最初の行で小さな編集を行うのではなく。
また、すべてのcronジョブに適用されるcrontabファイルにPATH変数を設定することもできます。 例えば
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin15 1 * * * backupscript --incremental /home /root私の一番上の問題：あなたはの最後に改行を追加することを忘れた場合 crontab ファイル。 つまり、crontabファイルは空の行で終わる必要があります。
以下は、この問題のmanページの関連セクションです（man crontab その後、最後までスキップ）:
Although cron requires that each entry in a crontab end in a newline character, neither the crontab command nor the cron daemon will detect this error. Instead, the crontab will appear to load normally. However, the command will never run. The best choice is to ensure that your crontab has a blank line at the end. 4th Berkeley Distribution 29 December 1993 CRONTAB(1)Cronデーモンが実行されていません。 私は本当に数ヶ月前にこれで台無しにしました。
タイプ:
pgrep cron 番号が表示されない場合（つまり、cronのメインPID）、cronは実行されていません。 sudo /etc/init.d/cron start cronを起動するために使用することができます。
編集：/etc/initを介してinitスクリプトを呼び出すのではなく。dは、サービスを利用して、例えば、
sudo service cron start編集：また、現代のLinuxでsystemctlを使用することもできます。
sudo systemctl start cronスクリプトのファイル名は、次のようになります。 cron.d/, cron.daily/, cron.hourly/、等。、ドットを含んではいけません(.）、そうでなければrun-partsはそれらをスキップします。
ランパーツを見る(8):
If neither the --lsbsysinit option nor the --regex option is given then the names must consist entirely of upper and lower case letters, dig‐ its, underscores, and hyphens. If the --lsbsysinit option is given, then the names must not end in .dpkg-old or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong to one or more of the following namespaces: the LANANA-assigned namespace (^[a-z0-9]+$); the LSB hierarchical and reserved namespaces (^_?([a-z0-9_.]+-)+[a-z0-9]+$); and the Debian cron script namespace (^[a-zA-Z0-9_-]+$).だから、もしあなたがcronスクリプトを持っていれば backup.sh, analyze-logs.pl で cron.daily/ ディレクトリ、あなたは最高の拡張子名を削除すると思います。
多くの環境では、cronは以下を使用してコマンドを実行します sh、多くの人々は、それが使用すると仮定しながら bash.
失敗したコマンドのためにこれをテストまたは修正するための提案:
でコマンドを実行してみてください sh それが動作するかどうかを確認するには:
sh -c "mycommand"Bashサブシェルでコマンドをラップして、bashで実行されることを確認します:
bash -c "mybashcommand"Crontabの先頭にシェルを設定して、bashのすべてのコマンドを実行するようにcronに指示します:
SHELL=/bin/bashコマンドがスクリプトの場合は、スクリプトにshebangが含まれていることを確認します:
#!/bin/bash私はタイムゾーンにいくつかの問題がありました。 Cronは新規インストールのタイムゾーンで実行されていました。 解決策はcronを再起動することでした:
sudo service cron restartスクリプトには絶対パスを使用する必要があります:
例えば, /bin/grep の代わりに使用する必要があります grep:
# m h dom mon dow command0 0 * * * /bin/grep ERROR /home/adam/run.log &> /tmp/errorsの代わりに:
# m h dom mon dow command0 0 * * * grep ERROR /home/adam/run.log &> /tmp/errorsこれは、シェルから実行されたときに同じコマンドが機能するため、特に注意が必要です。 その理由は cron 同じを持っていません PATH ユーザーとしての環境変数。
Crontabコマンドに % その中のシンボル、cronはそれを解釈しようとします。 コマンドを使用していたのであれば、 % その中で（dateコマンドの書式指定など）エスケープする必要があります。
それとここで他の良いgotchas:
http://www.pantz.org/software/cron/croninfo.html
Cronは実行可能ではないスクリプトを呼び出しています。
実行することによって chmod +x /path/to/script、スクリプトが実行可能になり、これはこの問題を解決する必要があります。
また、ユーザーのパスワードの有効期限が切れている可能性もあります。 Rootのパスワードでも有効期限が切れることがあります。 することができます tail -f /var/log/cron.log そして、あなたはcronがパスワードの有効期限が切れて失敗するのを見るでしょう。 パスワードの有効期限を設定するには、次のようにします: passwd -x -1 <username>
一部のシステム（Debian、Ubuntu）では、cronのログ記録はデフォルトで有効になっていません。 で /etc/rsyslog。conf または /etc/rsyslog。d/50-デフォルト。conf ザ-ライン:
# cron.* /var/log/cron.log編集する必要があります（sudo nano /etc/rsyslog.conf）にコメントされていない:
cron.* /var/log/cron.logその後、rsyslogを再起動する必要があります
/etc/init.d/rsyslog restartまたは
service rsyslog restart ソース: Debian Linuxでのcrontabログの有効化
一部のシステム（Ubuntu）では、cronの個別のログファイルはデフォルトでは有効になっていませんが、cron関連のログはsyslogファイルに表示されます。 一つは、使用することができます
cat /var/log/syslog | grep cron -icron関連のメッセージを表示するには。
Cronを有効にするには、crontab-eを閉じる必要があります。 たとえば、vimを使用してファイルを編集し、’：wを使用して書き込みますが、終了するまでジョブはcronに追加されません。 だから私はI'：qの後まで仕事を見ることはありません。
私はcronをデバッグする最善の方法は、syslogをチェックして問題を見つけることだと思います。
私の場合-電子メールは私のスパムフォルダに行っていたので、。… デバッグに時間を費やす前にそれを確認してください：D
これをチェックしてくださいhttps://askubuntu.com/a/1223213/297387