インフラ構築や運用自動化の過程において、手動でSSHターミナルから実行した際には正常に終了するスクリプトが、crontabによるスケジューリング実行時には無出力のまま停止、あるいはサイレントに失敗する現象は頻繁に発生します。この問題は、インタラクティブシェルとデモンプロセス経由の非対話型サブシェルにおける初期化ライフサイクルおよび環境変数の不一致に起因します。

本稿では、cron実行時の環境分離メカニズムを解説し、絶対パスの強制、ファイル実行権限、およびログリダイレクトストリームの構築手順を整理します。

SSH対話型環境とcrontab実行環境の構造的差異

手動実行とcron実行の決定的な違いは、シェル起動時にロードされる環境変数と構成ファイルにあります。

+-------------------------------------------------------------------------+
| SSH Interactive Shell Session                                           |
| Load files: ~/.bashrc, ~/.bash_profile, /etc/profile                    |
| PATH includes: /usr/local/bin, /usr/bin, /bin, user defined paths, etc. |
+-------------------------------------------------------------------------+

+-------------------------------------------------------------------------+
| Cron Daemon Execution Environment                                       |
| Load files: Minimal cron default parameters                             |
| PATH defaults to: /usr/bin:/bin                                         |
+-------------------------------------------------------------------------+

ユーザーがSSH経由でログインした場合、~/.bashrcや/etc/profileなどの初期化スクリプトが評価され、拡張されたPATHや独自環境変数が読み込まれます。一方、cronデモンは最小限の環境変数（多くの場合 PATH=/usr/bin:/bin のみ）が適用された非対話型サブシェルでジョブを実行します。そのため、標準パス以外の場所に配置されたバイナリや環境変数に依存するスクリプトは探索に失敗します。

3段階の診断および解決フレームワーク

1. 全コマンドおよびスクリプトへの絶対パス適用

cron設定において相対パスを使用すると、実行時のカレントディレクトリ解釈に不一致が生じ、エラーの原因となります。

相対パスを用いた失敗例:

* * * * * python main.py
* * * * * ./scripts/backup.sh

絶対パスを明示的に指定した設定例:

* * * * * /usr/bin/python3 /home/user/project/main.py
* * * * * /bin/bash /home/user/scripts/backup.sh

スクリプト内部で相対パスによるファイル読み込み（例: cat ./config.json）を行っている場合、実行ディレクトリがユーザーのホームディレクトリ（/home/user）に固定されるためエラーが発生します。必要に応じてスクリプトの先頭で移動処理を挿入するか、フルパスでの記述が必要です。

バイナリの絶対パスを確認するには、インタラクティブシェルで which コマンドを実行します。

which python3
which bash

2. ファイル実行権限（chmod）およびシバン（Shebang）の検証

スクリプトファイルに読取権限があっても実行権限（+x）が与えられていない場合、cronは処理を実行できません。

パーミッション状態の確認:

ls -l /home/user/scripts/backup.sh

実行権限が付与されていない場合、以下のコマンドで権限を付与します。

chmod +x /home/user/scripts/backup.sh

また、シェルスクリプトの1行目には適切なインタプリタを指定するシバンを明記します。

#!/bin/bash

3. 専用ログリダイレクトストリームの実装

cronはデフォルトで標準出力（stdout）および標準エラー出力（stderr）をターミナルに表示しません。ローカルMTA（Mail Transfer Agent）が未構成の場合、エラーログは記録されずに破棄されます。

実行結果およびエラーログをファイルへ連続記録するために、リダイレクト記述をcrontabに追加します。

* * * * * /bin/bash /home/user/scripts/backup.sh >> /home/user/cron.log 2>&1

🛠️ ログリダイレクトの構造分解: ・>> /home/user/cron.log: 標準出力（ファイル記述子1）をログファイルへ追記形式でリダイレクトします。 ・2>&1: 標準エラー出力（ファイル記述子2）を標準出力と同じストリームへ統合します。

Cron環境変数の明示的宣言と仮想環境の起動

crontabファイルの先頭領域にグローバル環境変数を定義することで、個別の実行ラインでフルパス記述を簡略化することが可能です。

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
SHELL=/bin/bash

* * * * * backup.sh >> /home/user/cron.log 2>&1

Pythonの仮想環境（venv や conda）を利用するスクリプトを呼び出す場合は、仮想環境内のPythonバイナリパスを直接指定して実行するのが確実な構成方法です。

* * * * * /home/user/myenv/bin/python /home/user/work/script.py >> /home/user/cron.log 2>&1

Troubleshooting

ケース1: cron実行時の Permission Denied またはサイレント失敗

⚠️ 原因: 実行スクリプトまたは内部で呼び出すバイナリの権限不足、またはシバン未指定。 💡 対処手順: chmod +x による権限の再設定、およびスクリプト先頭行の #!/bin/bash 存在確認を行ってください。

ケース2: システムログにcronの実行記録が表示されない

⚠️ 原因: ディストリビューションの設定によって /var/log/cron.log 出力が無効化されている。 💡 対処手順: /etc/rsyslog.d/50-default.conf を確認し、# cron.* 行のコメントアウトを解除後、systemctl restart rsyslog を実行してください。

ケース3: スクリプト内で参照する外部ファイルの読み込み失敗

⚠️ 原因: cron実行時のカレント作業ディレクトリが想定と異なる。 💡 対処手順: スクリプト内部の冒頭に cd “$(dirname “$0”)" などのパス移動ロジックを組み込むか、参照ファイル全般を絶対パスに変更します。

システム動作検証ログ

以下は、パーミッション確認、ログ出力設定、および syslog による CRON ジョブの動作確認ログ例です。

$ ls -l /home/user/scripts/backup.sh
-rw-r--r-- 1 user group 450 Nov  3 10:00 /home/user/scripts/backup.sh

$ chmod +x /home/user/scripts/backup.sh
$ ls -l /home/user/scripts/backup.sh
-rwxr-xr-x 1 user group 450 Nov  3 10:01 /home/user/scripts/backup.sh

$ grep CRON /var/log/syslog | tail -n 3
Nov  3 10:02:01 server CRON[12345]: (user) CMD (/bin/bash /home/user/scripts/backup.sh >> /home/user/cron.log 2>&1)
Nov  3 10:03:01 server CRON[12411]: (user) CMD (/bin/bash /home/user/scripts/backup.sh >> /home/user/cron.log 2>&1)

$ tail -f /home/user/cron.log
[2026-11-03 10:02:01] Starting backup process...
[2026-11-03 10:02:02] Backup completed successfully.

Operational Notes