crontabが動かない時のチェックリスト - PATH・環境・ログ

2026-06-05 読了時間: 約11分 難易度: 中級

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

• 手動では動くスクリプトが cron だと動かない 理由が分かる
• cron の失敗を ログから確認 する手順が分かる
• PATH・環境変数・時刻書式・パーミッションの 定番ハマりどころ を順に潰せる

なぜ手動では動くのに cron だと動かないのか？

結論: cron は対話ログインと違い .bashrc / .profile を読まない非対話シェルで、最小 PATH のまま実行する。手動成功・cron 失敗の大半はこの環境差が原因。

手動実行（ログインシェル）と cron 実行では、シェルの起動経路が根本的に違う。

この差を理解していれば、以降のチェックは「cron の最小環境で何が欠けているか」を 1 つずつ埋める作業になる。

cron デーモンは動いているか？

結論: まず systemctl status cron でデーモン稼働を確認する。停止していればジョブは一切実行されない。最初に潰すべき大前提。

# Ubuntu / Debian 系
$ systemctl status cron

# RHEL / CentOS 系
$ systemctl status crond

active (running) でなければ起動・有効化する。

$ sudo systemctl enable --now cron

実行されたかをログで確認するには？

結論: cron は起動のたびに syslog へ記録を残す。grep CRON /var/log/syslog にエントリが無ければ、ジョブはそもそも起動されていない。

ログに行があるか無いかで、切り分けの方向が大きく変わる。

# Ubuntu / Debian 系
$ grep CRON /var/log/syslog | tail -20

# systemd journal で見る場合
$ journalctl -u cron --since "1 hour ago"

# RHEL / CentOS 系
$ sudo grep CRON /var/log/cron | tail -20

実行されると次のような行が残る。

Jun  5 10:00:01 host CRON[12345]: (alice) CMD (/home/alice/backup.sh)

判定:

• ログにエントリがある → cron は起動済み。原因はスクリプト側（PATH / 権限 / 環境変数）。次節以降へ。
• ログにエントリが無い → そもそも起動されていない。時刻書式の誤り・crontab の設置場所・デーモン停止を疑う。

PATH が原因で動かないのはなぜか？

結論: cron の PATH は最小（多くは /usr/bin:/bin）。/usr/local/bin 等のコマンドは絶対パスで書くか、crontab 先頭で PATH を定義する。

「手動では動くのに cron で command not found」の典型はこれ。対処は 3 通り。

# 1) コマンドを絶対パスで書く（which で確認）
$ which node
/usr/local/bin/node

# crontab では絶対パス指定
* * * * * /usr/local/bin/node /home/alice/job.js

# 2) crontab の先頭で PATH を定義する
PATH=/usr/local/bin:/usr/bin:/bin
0 * * * * node /home/alice/job.js

# 3) スクリプト内で PATH を export してから処理する
#!/bin/bash
export PATH=/usr/local/bin:/usr/bin:/bin
node /home/alice/job.js

* * * * * env > /tmp/cronenv 2>&1

$ diff <(env) /tmp/cronenv

環境変数が無いせいで失敗していないか？

結論: cron は .bashrc / .profile を読まない。LANG や言語ランタイムの環境変数（NODE_ENV / JAVA_HOME 等）が未設定で落ちることが多い。

対話シェルで暗黙に設定されていた変数が、cron では空になる。スクリプト側で明示的に定義するのが最も確実。

#!/bin/bash
# cron 環境では未設定になりやすい変数を明示
export LANG=ja_JP.UTF-8
export HOME=/home/alice
export NODE_ENV=production

cd "$HOME/app" || exit 1
/usr/local/bin/node index.js

時刻指定・書式の間違いをどう見つけるか？

結論: フィールドは「分 時 日 月 曜日」の 5 つ。曜日と日の AND/OR、% のエスケープ漏れが定番のミス。ログに起動記録が無ければまず書式を疑う。

┌── 分 (0-59)
│ ┌── 時 (0-23)
│ │ ┌── 日 (1-31)
│ │ │ ┌── 月 (1-12)
│ │ │ │ ┌── 曜日 (0-7, 0と7は日曜)
│ │ │ │ │
* * * * *  実行するコマンド

つまずきやすい点:

• % はリテラルにならない: コマンド中の % は cron が改行に変換する。date +%Y-%m-%d は date +\%Y-\%m-\%d とバックスラッシュでエスケープする。
• 日と曜日の両指定: 0 0 1 * 1（毎月1日 かつ 月曜ではなく）は「1日 または 月曜」の OR で動く。意図とずれやすい。
• コメントは行末に置けない: * * * * * cmd # メモ は不可。コメントは独立行 # のみ。

パーミッションと crontab の設置場所を確認する

結論: スクリプトに実行権限が無い・shebang のパスが違うと起動直後に失敗する。/etc/cron.d/ 配置時はファイルにユーザー欄が必要な点も忘れやすい。

スクリプトの実行権限と shebang

$ chmod +x /home/alice/backup.sh
$ head -1 /home/alice/backup.sh
#!/bin/bash

Windows で編集したスクリプトは改行コード CRLF が混入し bad interpreter で失敗することがある。詳細は「bad interpreter」エラーの直し方を参照。

crontab の種類で書式が違う

# /etc/cron.d/ や /etc/crontab はユーザー欄が必須
# ┌分 ┌時 ┌日 ┌月 ┌曜 ┌ユーザー  ┌コマンド
  0   3   *   *   *   alice    /home/alice/backup.sh

ユーザー欄の有無を取り違えると、ログに Unauthorized 等のエラーが出るか、無言で実行されない。

出力をリダイレクトしてデバッグするには？

結論: cron は標準出力・標準エラーをメール送信する。MTA が無い環境では出力が消えるため、ファイルへリダイレクトしてエラーを可視化するのが確実。

# 標準出力と標準エラーをログファイルへ
* * * * * /home/alice/backup.sh >> /tmp/backup.log 2>&1

2>&1 で標準エラーも同じファイルに集約する。実行後に /tmp/backup.log を見れば、command not found や Permission denied の生メッセージが残る。

* * * * * date >> /tmp/cron-test.log 2>&1