cronが動かない原因と対処法 - crontabの使い方とログ確認

cronが動かない原因と対処法 - crontabの使い方とログ確認
読了時間: 約8分 難易度: 中級

この記事で解決できること

  • cron が「動かない」「実行されない」原因を体系的に切り分けられる
  • ログの場所と確認方法が分かる
  • 実務で頻発する「ユーザー・PATH・権限」の罠を避けられる

結論（障害対応の型）

cron が動かないときは、感覚で直さない。必ず次の順で見る。

  1. 本当に登録されているか
  2. どのユーザーの cron か
  3. ログに実行痕跡があるか
  4. 手動実行すると動くか
  5. PATH / 権限 / 実行ファイル問題

前提（対象環境）

  • OS：Ubuntu
  • 新人〜実務初期
  • root / 一般ユーザー両方を想定

1. cron の種類（ここを誤解すると詰む）

結論: ユーザーcron・root cron・/etc/cron.*があり、実行ユーザーが異なる。まずどこに書いたか明確にする。

Ubuntu には cron が複数あります。

1-1. ユーザー cron

$ crontab -e
  • 実行ユーザー：そのユーザー
  • 一番よく使う

1-2. root cron

$ sudo crontab -e
  • 実行ユーザー：root
  • 権限が必要な処理用

1-3. /etc/cron.*

  • /etc/cron.daily
  • /etc/cron.hourly など

どこに書いたかをまず明確にする

2. 登録されているか確認

結論: crontab -lとsudo crontab -lで登録内容を確認する。「登録したつもり」が最多の事故原因。

$ crontab -l
$ sudo crontab -l

「登録したつもり」が一番多い事故。

3. cron のログを見る（最重要）

結論: grep CRON /var/log/syslogかjournalctl -u cronで実行痕跡を確認。ログに出ない＝実行されていない。

3-1. syslog から確認

$ grep CRON /var/log/syslog

時間を絞る：

$ grep CRON /var/log/syslog | tail -n 50

3-2. journalctl で確認

$ journalctl -u cron

直近だけ：

$ journalctl -u cron -n 100

ログに出ていない＝実行されていない

4. 「実行されているが失敗している」ケース

結論: ログにCMDが出ていればcron自体は動いている。実行ユーザーで手動実行して原因を切り分ける。

ログに次が出ることがある。

CMD (/path/to/script.sh)

これは cron自体は動いている。

次にやること：

$ sudo -u <cron_user> /path/to/script.sh

5. 一番多い罠①：PATHが違う

結論: cronのPATHは極端に短い。コマンドはフルパスで書くか、冒頭でPATHを定義して回避する。

cron の PATH は極端に短い。

NG例

mysqldump ...

OK例

/usr/bin/mysqldump ...

対策：

  • フルパスで書く
  • 冒頭で PATH を定義
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

6. 一番多い罠②：実行権限がない

結論: Permission deniedが出たら実行権限不足。ls -lで確認しchmod +xで付与する。

Permission denied

確認：

$ ls -l script.sh

対処：

$ chmod +x script.sh

7. 一番多い罠③：相対パス

結論: cronは実行ディレクトリが不定。./script.shは避け、必ず絶対パスで指定する。

cron は どこで実行されるか分からない。

NG

./script.sh

OK

/home/user/script.sh

8. メール通知（失敗を可視化）

結論: MAILTOで失敗を通知できる。メールが来ない場合はMTA未設定かcron自体が動いていない。

cron は失敗時、メールを送る。

MAILTO=you@example.com

メールが来ない場合：

  • MTA未設定
  • そもそも cron が動いていない

9. cron が「重い処理」の犯人になるケース

結論: バックアップやrsync等の重い処理がI/O・CPU負荷の犯人になりやすい。負荷調査記事と併せて確認する。

  • バックアップ
  • ログ圧縮
  • rsync
  • Docker cleanup

ディスクI/O / CPU 記事と必ず繋がる

やってはいけないこと

  • ログを見ずに書き換える
  • root cron に何でも入れる
  • フルパスを書かない
  • 手動実行テストを省略する

コピペ用：cron 障害切り分けテンプレ

# 登録確認
crontab -l
sudo crontab -l

# ログ確認
grep CRON /var/log/syslog
journalctl -u cron -n 100

# 手動実行（実行ユーザーで）
sudo -u user /path/to/script.sh

次に読む