Linux サーバーで定期的な処理を自動化するために利用される cron。
しかし「設定したジョブが動かない」「ログに何も出ていない」という状況に直面することがあります。
本記事では、そんなときに確認すべき調査ポイントをステップごとに解説します。
目次
1. cron デーモンが稼働しているか確認する
まず基本中の基本として、cron サービス自体が起動しているかを確認します。
# systemctl status cron # Debian/Ubuntu 系
# systemctl status crond # RHEL/CentOS 系active (running)になっているか確認- 止まっていれば起動
sudo systemctl start cron sudo systemctl enable cron
2. crontab の書式ミスを確認する
cron は書式に非常に厳格です。
- 半角スペースの抜けや余分なスペースがないか
*の位置、分・時・日・月・曜日の並びが正しいか/や,の指定方法が間違っていないか
crontab -lを実行して内容を再確認しましょう。
3. PATH など環境変数の影響を確認する
cron は 最小限の環境変数 しか読み込みません。
そのため、手動実行では動くスクリプトが、cron では動かないことがあります。
例：PATH が原因でコマンドが見つからないケース
#!/bin/bash
/usr/bin/python3 /home/user/script.pyのように 絶対パス を指定しましょう。
必要なら crontab の先頭に以下を追加：
PATH=/usr/local/bin:/usr/bin:/bin4. 権限（ユーザー・実行権限）を確認する
- cron ジョブを設定したユーザーが正しいか
- 実行するスクリプトに 実行権限 (
chmod +x) が付与されているか rootでしか動かせないコマンドを一般ユーザーで実行していないか
ls -l /home/user/script.sh5. ログの出力先を明示する
cron は標準出力・標準エラーをメール送信する仕組みですが、環境によってはメールが無効化されている場合があります。
対策
cron の設定行にログ出力を明示的に追加：
* * * * * /home/user/script.sh >> /var/log/cron_script.log 2>&1これで、エラー内容を直接確認可能です。
6. シェルの違いに注意する
cron のデフォルトシェルは /bin/sh（環境によっては dash）です。
普段 /bin/bash で動かしているスクリプトは、cron 上では動かない可能性があります。
対策として、スクリプト先頭に明記：
#!/bin/bash7. 実行タイミングの確認（時間設定ミス）
- サーバーの タイムゾーン が想定と異なる可能性あり
0 0 * * *→ UTC の 0 時（日本時間だと午前 9 時）になるケース
timedatectlで確認しましょう。
8. SELinux や AppArmor の制限
セキュリティモジュールによって cron の実行がブロックされることもあります。
- SELinux 有効時は
/var/log/audit/audit.logを確認 - 必要に応じてポリシーを緩和
まとめ：調査ポイント対応表
| 調査項目 | 確認コマンド／対策 | よくある原因 |
|---|---|---|
| cron デーモン稼働確認 | systemctl status cron | サービスが停止している |
| crontab 書式確認 | crontab -l | スペースや指定ミス |
| PATH 設定 | echo $PATH / 絶対パス記載 | cron の環境変数不足 |
| 権限確認 | ls -l script.sh | 実行権限なし／ユーザー不一致 |
| ログ出力先指定 | >> /var/log/... 2>&1 | 出力がメールで消失 |
| シェル指定 | #!/bin/bash | sh と bash の違い |
| タイムゾーン確認 | timedatectl | 時間設定のずれ |
| SELinux / AppArmor | /var/log/audit/audit.log | セキュリティ制御による拒否 |