cron の出力を取得する

はじめに

Cron ジョブは、どのターミナルセッションからも切り離されたバックグラウンドで実行されます。自動化には非常に便利ですが、デバッグには課題があります。スクリプトが失敗しても、画面にエラーメッセージが表示されないためです。

Cron ジョブが出力を生成すると、従来のシステムでは、その出力をユーザーにメールで送信しようとします。しかし、多くの最新のサーバー、コンテナ、トレーニング環境ではメール配信が設定されていません。そのため、自分でリダイレクトしない限り、出力が実質的に消えてしまうことがあります。

これが、初心者が cron を難しいと感じる理由の 1 つです。ジョブはスケジュールどおりに実行されていても、エラーメッセージは crontab を作成したターミナルには表示されません。バックグラウンドで実行する自動化処理には、意識的なログ出力が必要です。

この実験では、この「見えない」出力を取得して、失敗の原因を調べる方法を学びます。次のことを行います。

まず、失敗をシミュレートするために、意図的に壊れたタスクを作成します。存在しないディレクトリを一覧表示するように cron へ指示します。

現在のユーザー用の crontab を開きます。

crontab -e

ファイルの末尾（コメントがある場合は、その下）へ移動し、次の行を追加します。

* * * * * ls /this/directory/does/not/exist

設定の詳細：

ファイルを保存して、エディターを終了します。

次に、少なくとも 1 分待ちます。

ターミナルを確認してください。 ...

画面には何も表示されません。これはサイレントな失敗です。コマンドは実行されて失敗し、エラーメッセージも生成されました。しかし、そのメッセージの出力先がなかったため、破棄されました。

何も表示されないからといって、「何も起きなかった」という意味ではありません。プロセスに対話型ターミナルが接続されていなかったという意味です。この違いを理解することは、スケジュールされたジョブをデバッグするうえで重要です。

エラーメッセージを確認するには、標準エラーストリーム（stderr）をファイルへリダイレクトします。

Linux では、ファイルディスクリプターに番号が付いています。

2>を使うと、チャネル 2（エラー）をファイルへリダイレクトできます。

これは、これまでに学んだシェルのリダイレクトモデルと同じ仕組みに基づいています。Cron がコマンドを起動し、シェルがファイルディスクリプターを処理し、リダイレクトによって各ストリームの出力先が決まります。

もう一度 crontab を開きます。

crontab -e

行を次の内容に正確に変更します。

* * * * * ls /this/directory/does/not/exist 2> /home/labex/project/cron_error.log

主な変更点：

2>：エラーストリームをリダイレクトします。
/home/labex/project/cron_error.log：ログファイルの絶対パスです。
- 重要：cron ジョブでは、必ず絶対パス（例：/home/labex/...）を使用してください。Cron は最小限の環境でコマンドを実行するため、~や相対パスが何を指すのか認識できません。

この最小限の環境も、cron を理解するうえで重要な概念です。スケジュールされたジョブでは通常、環境変数が少なく、PATHも限定されており、対話型シェルのコンテキストもありません。そのため、手動では動作するコマンドでも、暗黙の前提に依存していると cron では失敗することがあります。

保存して、終了します。