cronが動かないときに見るところ

レン

定期実行を設定したのに動かない…手で打つとちゃんと動くんだけど。

プロクラ

その症状、原因はほぼ決まっているよ。定期実行は、キミがログインしたときとは違う環境で動くんだ。

いちばん多い原因

手で実行すると動くのに定期実行では動かない、という形がほとんどです。理由は、定期実行が読み込む環境がログイン時とは違うためです。パスも環境変数も引き継がれません。書いたコマンドが悪いのではなく、動く前提が違っています。

プロクラ

ログインしたときは、設定ファイルが読み込まれて環境が整った状態になる。定期実行ではそれが起きない。だから、手で打てば通るコマンドが「見つからない」になる。

• コマンドをフルパスで書く（which で調べた結果をそのまま使う）
• 処理の中で使う環境変数を、その中で明示的に読み込む
• 作業ディレクトリを前提にしない。必要なら最初に移動する
• PATHを設定ファイルの先頭で指定してもよい

次に見るところ

• 書式が合っているか（分・時・日・月・曜日の5つ）
• 最終行が改行で終わっているか（終わっていないと読まれないことがある）
• 誰の設定として登録したか（rootと一般ユーザーで別々に持つ）
• サービス自体が動いているか
• 実行するファイルに実行権限があるか

プロクラ

3つめは意外と多いよ。rootで登録したつもりが一般ユーザー側に入っていて、権限が足りずに失敗している、という形だね。

何が起きたのかを見る

プロクラ

動かないときに一番困るのは、何も分からないことだよね。出力を捨てずに残す設定にしておけば、次からは原因がすぐ分かる。

• 実行結果を、エラーも含めてファイルへ書き出す
• システムのログにも、実行されたかどうかの記録が残る
• 「実行はされているが失敗している」のか「そもそも実行されていない」のかを、まず分ける

プロクラ

この切り分けが最初にできると、調べる範囲が半分になる。実行されていないなら書式や登録先の問題、実行されて失敗しているなら環境の問題だよ。

設定するときの習慣

• いきなり本番の時刻で登録せず、数分後に実行させて動作を確かめる
• 処理が重なると困るものは、二重に動かない仕組みを入れる
• ログを書き出す設定にしたら、そのログ自体の削除も設定する
• サーバーを移行するとき、この設定は移し忘れやすい

レン

手で打つときと環境が違う。それが分かれば納得だ。

cron以外の選択肢

プロクラ

定期実行の仕組みは1つではないよ。最近のOSには、失敗したときの再試行や、前回の実行結果を持つものも用意されている。

• systemdのタイマー: 実行結果や失敗の記録が残り、状態を確認しやすい
• サーバーが止まっていた間の分を、起動後に実行させることもできる
• アプリ側に定期実行の仕組みがあるなら、そちらに寄せる手もある
• どれを使うにせよ、実行されたかを後から確認できることが大事