cronジョブが実行されない

crontabに登録したはずのジョブが、なぜか実行された形跡がない——という状況を切り分けていきます。

どんな症状か

crontab -l で登録自体は確認できるのに、期待した時刻に処理が実行された形跡がない。あるいは、手動で同じコマンドを打つと動くのに、cron経由だと動かない、というケースです。

原因を切り分ける

ステップ1：cronが実際に動いたかログで確認する

$ grep CRON /var/log/syslog | tail -5

環境によっては journalctl -u cron や journalctl -u crond で確認します。ここに何も出ない場合、cronサービス自体が動いていない可能性があります。まず systemctl status cron（環境によっては crond）でサービスの状態を確認します。

ステップ2：crontabの書式・時刻指定を確認する

$ crontab -l
30 2 * * * /home/alice/backup.sh

左から「分 時 日 月 曜日」の順です。指定を書き間違えていないか、想定していた時刻とサーバーのタイムゾーンが一致しているか（date コマンドでサーバー時刻を確認）も合わせて確認します。

ステップ3：環境変数・PATHの違いを疑う

cronは、対話的にログインしたときのシェルとは異なる、最小限の環境変数でジョブを実行します。そのため、ターミナルで手動実行すると動くのに、cron経由だと command not found 相当の理由で失敗することがよくあります。スクリプト内のコマンドはフルパスで書く（例：python3 ではなく /usr/bin/python3）か、スクリプトの先頭で必要な環境変数を明示的に設定するのが安全です。

ステップ4：実行結果をログに残す

30 2 * * * /home/alice/backup.sh >> /home/alice/backup.log 2>&1

crontabの行末にリダイレクトを追加しておくと、標準出力・標準エラー出力がログファイルに残るので、次に失敗したときの原因調査がぐっと楽になります。

解決方法

• cronサービス自体が停止していた場合： systemctl start cron（環境によっては crond）で起動します。
• 時刻指定のミスの場合： crontabの書式を修正します。
• PATH・環境変数が原因の場合： スクリプト内のコマンドをフルパスに書き換える、または必要な環境変数をスクリプト内で明示的に設定します。
• 今後の調査に備える場合： ログを残す設定にしておきます。