cronの仕組み — 毎朝7時にレポートを作る予約を読む

ひよこ

毎朝同じコマンドを実行するの、忘れそう…。

ペンギン先生

cronを使うと、決めた時刻にコマンドを起動する予約ができるよ。Linuxなどで使われるスケジューラーだけど、環境によっては導入やサービスの起動が必要なんだ。

ひよこ

どんな予約の書き方なの？

ペンギン先生

ユーザーのcrontabでは、分・時・日・月・曜日の5項目の後にコマンドを書くよ。0 7 * * *なら毎朝7時。まずはレポートを作るコマンドを手動で動かし、その後で予約しよう。

ひよこ

裏側ではどう動くの？

ペンギン先生

cronのデーモンが時刻と設定を照合し、条件に合うコマンドを起動するよ。通常は分単位の指定で、登録したユーザーの権限で動く。秒ぴったりの実行や、処理の成功まで保証するものではないんだ。

ひよこ

手動で動くのに、cronでは失敗することがある？

ペンギン先生

あるよ。使うシェル、PATH、作業場所などが普段のターミナルと違うことがある。cronも通常はシェルを使うけど、対話用の設定が同じように読まれるとは限らない。実行ファイルやデータの場所を明示しよう。

ひよこ

失敗したらどう気づけばいい？

ペンギン先生

標準出力とエラーをログに残し、結果のファイルや終了状態を確認しよう。cronの起動記録だけでは成功と判断できないよ。出力のメール配送も、メールを送れる環境がある場合の話なんだ。

ひよこ

毎月1日の月曜日だけ、という指定もできる？

ペンギン先生

一般的なcrontabでは、日と曜日を両方制限すると「どちらかに合う日」になるよ。例えば0 7 1 * 1は、毎月1日と毎週月曜の7時。両方一致する日だけ、と思わないようにね。

ひよこ

前の処理が終わらないまま次の時刻になったら？

ペンギン先生

重ねて起動することがあるよ。時間がかかる処理ではロックや実行中の判定を検討する。複数マシンなら各台で動く可能性もあり、1台のロックだけでは防げないんだ。

ひよこ

パソコンが止まっていた分は後から動く？

ペンギン先生

通常のcronの予約だけで、必ず取り戻せるとは言えないよ。必要なら取り逃しを扱う別の仕組みを選ぶ。タイムゾーンや夏時間の扱いも実装によって確認し、「いつ・誰の権限で・何ができたら成功か」を残そう。

まずは、予約する前にレポートを1回作る

cronは、コマンドを時刻に合わせて起動する仕組みです。Linuxなどの練習用環境で、cronが導入されサービスが動いていることを確認してから使います。Windowsのタスクスケジューラーとは別の道具です。

まずは新しい練習用フォルダーにreport.pyを保存してください。Python 3で、自分のフォルダー内だけへ結果を書きます。

from datetime import datetime
from pathlib import Path

report = Path(__file__).with_name(
    'report.txt'
)
now = datetime.now().astimezone()
time_text = now.isoformat(timespec='seconds')
message = 'レポート作成完了: ' + time_text
report.write_text(
    message + '\n', encoding='utf-8'
)
print('created:', report)

そのフォルダーでpython3 report.pyを実行します。report.txtができ、時刻とタイムゾーン付きのメッセージが入れば、まず1回は動かせています。この例は実行ごとに自分のreport.txtを上書きします。実際の集計データを作る処理ではありません。

予約の1行を分解する

次はユーザー個別のcrontabの例です。crontab -lで今の内容を確認し、crontab -eで編集します。既存の予約を消さず、実行ファイルとフォルダーの場所を先に調べてください。

0 7 * * * /usr/bin/python3 /home/hiyoko/cron-lab/report.py >> /home/hiyoko/cron-lab/report.log 2>&1

/usr/bin/python3と/home/hiyoko/cron-lab/は例のパスです。自分のLinux環境でcommand -v python3とpwdを実行し、確認した場所へ置き換えます。スペースのあるパスはシェルの引用にも注意してください。上の例では、作業場所に頼らずreport.pyと同じ場所へ結果を保存するようにしています。

>>はログへの追記、2>&1はエラー出力も同じ行き先へ送る指定です。予約したあとには、次の3点を別々に確かめましょう。

• 予約が残っていて、cronが動いているか。
• report.logに実行の出力やエラーが残っているか。
• report.txtの内容が、今回の実行で更新されたか。

cronの起動記録だけを見て「完成した」と判断しないことが大切です。ログも増え続けるので、保管と削除の方針を決めます。

もう少し詳しく：条件の落とし穴

0 7 1 * 1は、日と曜日の両方を制限しています。一般的なcrontabでは、毎月1日、または月曜日の7時に実行します。「1日かつ月曜日だけ」という意味ではありません。

*/15を分へ指定すると、0・15・30・45分に合います。「前回終了から15分後」ではなく、分のフィールドに合う時刻です。シェルに渡る部分の%は、通常のコマンド実行と違う扱いになる実装もあるため、複雑な処理は別スクリプトに分けて確認しましょう。

cronも通常は/bin/shなどのシェル経由でコマンドを実行します。ただし普段使う対話シェルと環境変数、初期化ファイル、権限が同じとは限りません。ユーザーのcrontabと、ユーザー名の欄を持つシステム用crontabも区別してください。

取り逃し・重複・時刻も設計する

処理が長引けば、次の予約が前の実行と重なる場合があります。ロックで起動を見送るのか、待たせるのか、重複しても同じ結果になるようにするのかを、業務に合わせて決めます。複数マシンに同じ予約を登録した場合は、1台のファイルロックだけでは解決しません。

停止中の実行を補う必要がある場合は、それに対応するスケジューラーや、処理済みの期間を記録する方法を検討します。クラウドの仕組みを使っても、対象処理の失敗や重複をどう扱うかは残ります。

タイムゾーンと夏時間の扱いは、利用するcronの実装・設定で確認してください。CRON_TZなどの拡張が使えるかも環境によります。UTCで統一するか、現地の営業時間に合わせるかは目的で決めます。

覚え方と次の一歩

「cron」って出てきたら「時刻に合わせてコマンドを起動する予約係」と思えばだいたいOK！

ファイル操作から確認するならLinux入門、実行結果を追うならログ収集の仕組みへ進めます。

参考資料

• Cronie：crontab(5) — 5項目の構文、実行シェル、日と曜日のOR条件、時刻と拡張
• Cronie：cron(8) — デーモンの動作と時刻の扱い