cronでPATHが通らない原因と対策｜絶対パス・環境変数の確認方法
cronは対話シェルと同じ環境で動くとは限りません。手動実行では成功するのにcronだけ失敗する場合、PATH・実行ユーザー・カレントディレクトリ・環境変数を確認します。
このページで分かること
- cronとログインシェルの環境差
- 絶対パスとPATHの安全な設定
- 実行ユーザーで再現する方法
先に結論
このページの役割： このページは、cronとログインシェルの環境差、PATH不足、絶対パスの指定に特化しています。cronが動かない原因全般はcronトラブル解決ガイドを参照してください。
cronではコマンド・スクリプト・入出力先を絶対パスで指定し、必要なPATHや環境変数をcrontabまたはスクリプト内で明示するのが安全です。
cron設定を作成・確認する
実行時刻、ユーザー、コマンド、ログ出力を入力して、登録前の注意点を確認できます。
なぜcronだけPATHが違うのか
cronはログインシェルを開いてコマンドを実行するわけではありません。.bashrcや.profile、alias、シェル関数が読み込まれる前提にすると、手動実行との差が生まれます。
実際の既定PATHや環境はcron実装・ディストリビューション・設定ファイルによって異なるため、必要な値は明示するのが安全です。
よくある症状
command not foundになる- PythonやNode.jsのバージョン管理ツール配下のコマンドが見つからない
- 相対パスで指定した設定ファイルや出力先が見つからない
- 手動では動くが、cronでは別ユーザーとして失敗する
- 標準エラーを捨てており、原因が見えない
安全な設定例
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
15 2 * * * /usr/local/bin/backup.sh >> /var/log/example-backup.log 2>&1
スクリプト内でも利用ファイルを絶対パスにします。
#!/bin/bash
set -eu
/usr/bin/rsync -a /srv/data/ /backup/data/
/usr/bin/date '+%F %T backup completed'
秘密情報： パスワードやAPIキーをcrontabへ直接書くと、閲覧権限やプロセス情報から漏れる可能性があります。権限を制限した設定ファイルや安全な資格情報管理を利用してください。
実行ユーザーで再現する
cronが動くユーザーと同じユーザー・近い環境で手動実行すると、権限やPATHの差を見つけやすくなります。
sudo -u appuser env -i \
HOME=/home/appuser \
SHELL=/bin/sh \
PATH=/usr/bin:/bin \
/usr/local/bin/backup.sh
/etc/cron.dでは時刻フィールドの後に実行ユーザー欄があります。ユーザーcrontabにはユーザー欄を付けません。
ログの残し方
15 2 * * * /usr/local/bin/backup.sh >> /var/log/example-backup.log 2>&1
書き込み先ディレクトリに実行ユーザーの権限があるか確認します。cronデーモンのログは環境によりjournal、syslog、専用ログへ出力されます。
journalctl -u crond --since today
journalctl -u cron --since today
grep CRON /var/log/cron /var/log/syslog 2>/dev/null
確認チェックリスト
- 登録先は正しいユーザーのcrontabか
- コマンドとスクリプトを絶対パスで指定したか
- スクリプト内のファイル・出力先も絶対パスか
- 必要なPATH・HOME・SHELL・ロケールを明示したか
- 実行ユーザーに読み書き・実行権限があるか
- 標準出力と標準エラーを確認できるか