cron による定期実行のしくみ
決まった時刻や間隔でコマンドを自動実行したいときは cron を使います。cron は常駐しているデーモン（crond）が一定間隔で予定表を読み、時刻が来たコマンドを起動するしくみです。各ユーザは自分専用の予定表（crontab）を持ち、ログイン中でなくても処理が動きます。バックアップ・ログの整理・通知などの定例作業を人手なしで回せるのが利点です。
決まった時刻になると自動でコマンドを動かしてくれるしくみ、それが cron だ。読み方は「クロン」で、ギリシャ語の chronos（時間）に由来する。
毎晩バックアップを取る。1時間ごとに一時ファイルを掃除する。月初に集計メールを送る。こういう繰り返しの定例作業を、機械に肩代わりさせられる。
人がやると、忘れたり手順を間違えたりする。cron はそれを正確に代行する。これが最大の価値だ。
一度仕込んでおけば、あなたがログアウトしていても、決めた時刻が来れば処理は静かに動く。Linuxでこの定期実行を担う、最も古くからある定番のしくみが cron である。サーバ運用の自動化を学ぶなら、まず最初に身につけたい基礎だ。
⏰ 時間を見張っているのは crond
cron の中心にいるのは crond（cron daemon）という常駐プログラムだ。デーモンとは、画面を持たず背景でずっと動き続けるサービスのことをいう。
crond はシステムが起動するとともに立ち上がり、以後ほぼ1分ごとに目を覚ます。そして「いま実行すべき予定はないか」を確認する。
その予定が書かれた表のことを crontab（cron table）と呼ぶ。crond は登録されている crontab を読み、各行に書かれた実行時刻と現在時刻を突き合わせ、一致した行のコマンドだけを起動する。
つまり「1分ごとに予定表をめくり、時間が来たものを実行する受付係」が常駐している、とイメージすると分かりやすい。
では、その受付係自身が眠っていたら何も起きない。crond が動いているかどうかは systemctl status crond（ディストリビューションによっては cron）で確認できる。止まっていれば、どんなに正しく予定を書いても実行されない。「登録したのに動かない」ときに最初に見るべき場所のひとつだ。
👥 予定表は誰のもので、どう編集するのか
cron の予定表は、システム全体で1つではない。各ユーザが自分専用の crontab を持てる。
user01 が登録した予定は user01 の権限で、root が登録した予定は root の権限で実行される。これにより、一般ユーザが自分の作業だけを自動化したり、管理者がシステム全体の保守を仕込んだりを、互いに干渉せず行える。
自分の crontab を編集するには crontab -e を使う。これを実行するとエディタが開き、保存して閉じると内容が検証されて登録される。登録済みの内容を確認するには crontab -l、まるごと削除するには crontab -r だ。
ここに落とし穴がある。crontab -r は確認なしで全消去してしまう。内容を見たくて -l（小文字のエル）と打つつもりが、隣の -r を押してすべて消す、という事故が起きやすい。
心配なら crontab -l > ~/crontab.bak のように、定期的に現在の内容を控えておくと安全だ。
編集時に開くエディタは EDITOR 環境変数で決まる。意図せず vi が開いて操作に困る、という初学者のつまずきが多い。export EDITOR=nano のように普段使うエディタを指定しておくと安心だ。
なお、他人の crontab を扱うには管理者権限が必要だ。root は crontab -u user01 -e のように -u で対象ユーザを指定して編集できる。
誰が cron を使えるかは /etc/cron.allow と /etc/cron.deny で制御されている。環境によっては一般ユーザの利用が制限されていることもある。「自分は使えるはずなのに crontab -e がはねられる」なら、まずこの2ファイルを疑うとよい。
🗂 システム全体の定例はどこに置くのか
ユーザごとの crontab とは別に、システム全体で動かす定期処理のしくみもある。/etc/crontab や /etc/cron.d/ 配下のファイルがそれだ。これらは書式に「実行ユーザ」の列が1つ増えるのが個人用との違いになる。
アプリケーションが自分の定期処理を登録するときは、この /etc/cron.d/ にファイルを1つ置く形がよく使われる。
さらに手軽な方法もある。/etc/cron.daily/、/etc/cron.weekly/、/etc/cron.monthly/、/etc/cron.hourly/ というディレクトリだ。ここに実行権を付けたスクリプトを置くだけで、それぞれ毎日・毎週・毎月・毎時に実行される。
細かい時刻指定が要らない定例処理なら、書式を覚えなくてもファイルを置くだけで済む。ログのローテーション（logrotate）など、OSが標準で用意する多くの定期処理も、このしくみで動いている。
📬 動いたか動かなかったか、どこで知るのか
cron で動かした処理は、画面に結果が出ない。だから「動いたのか動いていないのか分からない」状態になりがちだ。まずはどこを見ればいいのか。
crond は実行したことを /var/log/cron（ディストリビューションによっては journal）に記録する。ここを見れば「起動された形跡」は追える。
ただしこのログに残るのは「起動したこと」だけだ。ジョブの中身が成功したか失敗したかまでは分からない。
そこで効いてくるのが、cron の挙動だ。cron はジョブが標準出力や標準エラーに何か出力すると、その内容をそのユーザ宛のメールとして送ろうとする。
メール配送が設定されていない環境では送れずに終わる。だがこの性質を逆手に取れる。コマンドの末尾に >> /var/log/myjob.log 2>&1 のように書いて、出力とエラーを自分でログファイルへ追記しておくのが定番の作法だ。
こうしておけば、後から「いつ・何が・どう失敗したか」を確実にたどれる。結果メールの宛先は、crontab の冒頭に MAILTO=you@example.com と書いて指定することもできる。
⚖ cron に向く仕事と、向かない仕事
万能に見える cron にも、得意と不得意がある。cron は「決まった周期で軽い処理を回す」のが得意だ。
一方で限界もある。1分より細かい間隔の実行はできない。電源が切れていた間に逃した実行は後から取り戻せない。依存関係（Aが終わってからB）は書けない。
これらが問題になる場面では、後の項で扱う systemd timer や、1回だけの予約に向く at が選択肢になる。
逆に言えば、毎日や毎時の定例処理のように要件が素直なら、cron はいまでも最短で仕込める手堅い選択肢だ。
まずは「定期実行といえば cron、その実体は crond が crontab を1分ごとに読んで動かしている」という全体像を押さえておけば、書式や応用といった各論の理解がぐっと早くなる。次の項では、その crontab に書く1行の書式を詳しく見ていく。