cron

スケジュールを読んで指定時刻に別環境でジョブを起動し、結果をログと監視へ渡す予定、実行条件、重複制御、結果確認を分離する

crontabの五つの時刻フィールド

一般的な利用者crontabは、左からminute、hour、day of month、month、day of weekの五フィールドとコマンドを書きます。asteriskは全候補、commaは列挙、hyphenは範囲を表す基本構文です。

system-wideのcrontabでは、時刻フィールドとコマンドの間に実行利用者を置く実装があります。利用者crontabへ同じ形式を複製すると、利用者名をコマンドとして実行して失敗します。対象環境の手動を確認します。

起動までを順に確認する

1. Schedule時刻フィールドが現在時刻に一致するか、タイムゾーンとカレンダー条件を評価する。
2. Userそのcrontabの所有者または指定利用者の権限で処理を起動する。
3. EnvironmentSHELL、HOME、LOGNAME、限定されたPATHなど、cronの環境を準備する。
4. Commandシェルを通してコマンドを実行し、stdout、stderr、終了状態を発生させる。
5. Observationログ、メール、監視サービスへ結果を残し、失敗や未実行を検知する。

端末と同じ環境ではない

ログインシェルの設定ファイルが読まれず、PATHが短い場合があります。端末では動くコマンドがcronでは「見つからない」原因になります。実行ファイルは絶対パスで指定し、必要な環境変数を明示します。

作業ディレクトリーも自動でプロジェクトフォルダーになるとは限りません。最初に安全なディレクトリーへ移動し、入力ファイルと出力ファイルの絶対パス、文字コード、localeを決めます。

パスワードをcrontabへ直接書かない

crontabは同じ利用者や管理者から読める場合があり、処理一覧やエラーメールへ引数が出ることもあります。データベースパスワードやAPIトークンは権限を制限した秘密情報ファイルや秘密情報管理者から読みます。

ルートで動かす必要がないバックアップや集計をルートcrontabへ置きません。ジョブ専用利用者と、読書き先の最小権限を用意します。

前回が終わる前に次回が始まる

10分ごとのジョブが15分かかれば、次のインスタンスと重なります。同じファイルや表を同時更新すると破損や二重処理につながります。OSのファイルロック、データベースの助言ロック、ジョブ管理表などで排他します。

異常終了後も残る単純な「ロックファイルの存在」だけに頼ると、永久に止まる場合があります。処理と結び付くロックか、有効期限と所有者を検証できる方式を使います。

同じジョブを再実行しても壊れないようにする

失敗後の手動再実行やサーバー二重化に備え、同じ対象を二度処理しても結果が重複しないidempotent（アイデンポテント、冪等）な設計にします。処理済みID、一意制約、期間ごとのチェックポイントを持ちます。

途中まで成功した複数処理を一括トランザクションにできない場合、再開地点と補償処理を記録します。

電源OFF中の予定は通常そのまま過ぎる

伝統的なcronは、予定時刻にOSやデーモンが動いていなければ、そのジョブを後から必ず穴埋めする仕組みではありません。PC起動後に日次ジョブを実行したい場合はanacronやsystemdタイマーなど、catch-up機能を持つ仕組みを検討します。

クラウドインスタンスの再作成やメンテナンス時間窓も含め、「一度も抜けてはいけないジョブ」はデータベース待ち行列や管理対象スケジューラーで実行履歴を管理します。

タイムゾーンとDSTで回数が変わり得る

cronデーモンが使うタイムゾーンを確認します。サーバーをUTC、業務時刻を日本時間とする場合、スケジュールの変換と日付境界を明示します。

夏時間を使う地域では、時計が進んで存在しない時刻や、戻って二度現れる時刻があります。実装の動作を確認し、課金や締処理は「最後に完了した期間」をデータとして持ちます。

起動ログだけで成功と判断しない

開始・終了時刻、対象範囲、処理件数、終了状態、エラーを構造化して残します。stdoutとstderrの配送先を決め、0以外の終了、予定時刻までに成功記録がないこと、異常に長い実行を監視します。

cronの設定確認では「何時に見えるか」だけでなく、誰の権限・どの環境・どのディレクトリー・何回起動し・成功をどこで確認するかまで一組にします。

crontabの形式と実行環境の確認資料：The Open Group Base Specifications「crontab」