【Ubuntu】cron の基本:動かない理由の切り分けとログ確認(実行ユーザー・環境の罠)
この記事で解決できること
- cron が「動かない」「実行されない」原因を体系的に切り分けられる
- ログの場所と確認方法が分かる
- 実務で頻発する「ユーザー・PATH・権限」の罠を避けられる
結論(障害対応の型)
cron が動かないときは、感覚で直さない。必ず次の順で見る。
- 本当に登録されているか
- どのユーザーの cron か
- ログに実行痕跡があるか
- 手動実行すると動くか
- PATH / 権限 / 実行ファイル問題
目次
前提(対象環境)
- OS:Ubuntu
- 新人〜実務初期
- root / 一般ユーザー両方を想定
1. 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
「登録したつもり」が一番多い事故。
3. 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 (/path/to/script.sh)
これは cron自体は動いている。
次にやること:
$ sudo -u <cron_user> /path/to/script.sh
5. 一番多い罠①: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 script.sh
対処:
$ chmod +x script.sh
7. 一番多い罠③:相対パス
cron は どこで実行されるか分からない。
NG
./script.sh
OK
/home/user/script.sh
8. メール通知(失敗を可視化)
cron は失敗時、メールを送る。
MAILTO=you@example.com
メールが来ない場合:
- MTA未設定
- そもそも cron が動いていない
9. cron が「重い処理」の犯人になるケース
- バックアップ
- ログ圧縮
- 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
検証環境
本記事のコマンドは Ubuntu 24.04 LTS / bash 5.2 で動作確認済みです。