cronの仕組み — Linuxの定時実行はどう動いている？

cronはUnix/Linuxに標準搭載されているジョブスケジューラだよ。バックグラウンドでずっと動いている「デーモン」で、決まった時間に決まったコマンドを自動で実行してくれるんだ。例えば「毎朝3時にデータベースのバックアップを取る」とか「5分ごとにログを集計する」とか、定期的なタスクを人間の代わりにやってくれるんだね。

crontabという設定ファイルに書くんだけど、5つのフィールドで時間を指定するよ。左から「分（0-59）」「時（0-23）」「日（1-31）」「月（1-12）」「曜日（0-7）」の順番。例えば「30 3 * * *」なら毎日3時30分、「0 */2 * * *」なら2時間ごと、「0 9 * * 1-5」なら平日の9時に実行という意味だね。アスタリスク * は「毎回」を意味するよ。

cronのデーモン（crond）は、実はすごくシンプルな仕組みだよ。毎分1回目を覚まして、登録されている全crontabエントリを確認する。現在時刻とマッチするエントリがあれば、子プロセスをforkして該当コマンドを実行するんだ。実行が終わったらそのプロセスは終了。cronデーモン自体はまた次の1分を待つ、の繰り返しだね。

大きく3種類あるよ。まず「crontab -e」コマンドで編集するユーザー個別のcrontab。これは /var/spool/cron/ 以下に保存される。次に /etc/cron.d/ ディレクトリに置くシステム管理用のcrontab。そして /etc/cron.daily/ や /etc/cron.hourly/ のようなディレクトリにスクリプトを置くだけで、日次・時間次で実行してくれる仕組みもあるんだ。用途に応じて使い分けるのがポイントだね。

あるある！一番多いのはPATHの問題だね。ターミナルで手動実行するときは ~/.bashrc で設定されたPATHが使えるけど、cronはシェルを経由しないから最小限のPATHしか持っていない。だから /usr/local/bin/python とフルパスで書くか、crontabの先頭に PATH=/usr/local/bin:/usr/bin:/bin と書く必要があるよ。あと、cronの標準出力はメール（sendmail）に送られるから、ターミナルには何も表示されない。ログファイルにリダイレクトするのが定石だね。

systemdタイマーが有力な代替だよ。.timerファイルと.serviceファイルのペアで定義するんだけど、cronにはない便利機能がたくさんある。「前回の実行完了から30分後」のような相対指定、他のサービスとの依存関係の定義、実行ログのjournalctlでの一元管理、ランダム遅延でサーバー負荷を分散する機能などがあるんだ。カレンダーイベント形式で「OnCalendar=Mon..Fri 09:00」みたいに書けるのも直感的だね。

いいところに気づいたね。クラウド環境ではマネージドなスケジューラを使うのが主流だよ。AWSならEventBridge（旧CloudWatch Events）、GCPならCloud Scheduler、AzureならAzure Functionsのタイマートリガーがある。KubernetesにもCronJobリソースがあって、Podを定期的に起動できる。サーバーが落ちてもスケジューラ自体はクラウド側が管理してくれるから安心だね。

まさにそれが分散cronの最大の課題で、「exactly-once実行」問題と呼ばれるよ。複数ノードに同じcrontabがあると全台で同時実行されてしまう。対策としてはリーダー選出（1台だけが実行権を持つ）やRedisなどを使った分散ロックがあるけど、ネットワーク分断時にどうするかなど難しい問題が残る。HashiCorpのNomadやUber製のPeratorなど、専用の分散スケジューラも登場しているんだ。

ベテランが口を揃えて言うのが「タイムゾーンの罠」と「誰も知らないcronジョブ」問題だね。夏時間（DST）切り替え時に、午前2時台のジョブが2回実行されたり、逆にスキップされたりする。UTCで統一するのが鉄則だよ。そして本当に怖いのは、何年も前に誰かが設定したcronジョブが誰にも引き継がれず、そのサーバーを退役させた途端にシステム障害が起きるパターン。cronジョブの棚卸しとドキュメント化は、地味だけど本当に大事な運用タスクだね。