この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
crontabの設定ミスは、単純な「1つのエラー」では終わりません。間違えた内容によっては同じ処理が何十回も繰り返され、サーバー全体を重くしてしまうことがあります。これは2004年、私がSEとして客先常駐していた頃に実際に経験した出来事です。
この記事では、3,100名以上を指導してきた私が、crontabの設定ミスで深夜に呼び出された体験談と、そこから現場で学んだcron運用の3つの鉄則を解説します。
この記事のポイント
・時刻欄の「0」を「*」にするだけでジョブが毎分実行される
・出力先を設定しないとcronがroot宛メールを送り続ける
・cron実行環境はシェルと異なりPATHが短く、明示的な設定が必要
・本番投入前の「手動実行確認」でこれらの事故は防げる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
深夜2時に呼び出された経緯
2004年のことです。私は客先常駐のSEとして、あるWebシステムのLinuxサーバー運用を担当していました。そのシステムでは毎晩2時0分にバックアップスクリプトを自動実行するcronジョブが動いていました。ある日、「実行時刻を少し調整してほしい」と担当者から依頼を受けた私は、crontabをviで開いて時刻欄を修正しました。変更自体は1行だけだったので、「簡単な作業だ」と軽い気持ちで進めたのが災いしました。
# 変更前：毎日2時ちょうどに実行 0 2 * * * /scripts/backup.sh >> /var/log/backup.log 2>&1 # 変更後：私が書いてしまったもの * 2 * * * /scripts/backup.sh >> /var/log/backup.log 2>&1
深夜2時0分から重いバックアップ処理が始まり、1回目が終わらないうちに2時1分の2回目が起動。2時2分には3回目が……。プロセスが積み重なるにつれてディスクI/Oが飽和し、サーバーの応答が極端に遅くなりました。深夜2時半過ぎ、当番だった同僚から「サーバーが重い、何かしたか？」という連絡が入りました。
なぜこのミスが起きたのか
あの夜の経験を振り返ると、ミスの背景には3つの原因がありました。セミナーで3,100名以上を指導してきた中で、全く同じパターンを何度も見かけます。1. 変更後に「crontab -l」で確認しなかった
crontabを編集した後、crontab -lで実際の設定内容を表示して確認する習慣がありませんでした。「変更前と変更後の内容」を並べて見直していれば、すぐに気づけたはずのミスです。2. 「簡単な変更だから」と動作確認を省略した
1行だけの変更なのに、変更後の動作確認を一切しませんでした。cronの時刻フィールドは短い記述に多くの意味が凝縮されています。「0」と「*」の違いは小さく見えますが、実際の挙動は天と地ほど異なります。3. cronの実行環境がシェルと異なることを理解していなかった
当時の私は、ターミナルで手動実行できればcronでも同じように動くと思い込んでいました。実際にはcronが実行するシェルはPATHや環境変数が最小限に設定されており、ターミナルでは動くのにcronでは動かない——という問題は頻繁に起きます。あの夜の経験から学んだ3つの鉄則
20年以上サーバーを運用してきた経験から言うと、以下の3点を習慣化しているだけで、cron絡みのトラブルは大幅に減ります。1. 編集直後は「crontab -l」で必ず表示確認する
crontabを保存した直後に、必ずcrontab -lで設定内容を目視確認します。時刻フィールドの「分・時・日・月・曜日」を一つひとつ指差しで確認する習慣が、このような凡ミスを防ぎます。# 設定後、必ずこのコマンドで確認する $ crontab -l # 出力例（5フィールドを目視確認） 0 2 * * * /scripts/backup.sh >> /var/log/backup.log 2>&1
2. 本番投入前にスクリプトを手動実行して動作確認する
cronに登録する前に、対象スクリプトをターミナルから直接実行して問題ないことを確認します。さらにcronの環境に近づけるために、crontabにPATHやSHELLを明示的に設定することも重要です。# crontab内で環境変数を明示的に設定する例 SHELL=/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin MAILTO="" # これにより、ターミナルとcronの環境差を吸収しやすくなる 0 2 * * * /scripts/backup.sh >> /var/log/backup.log 2>&1
3. 出力はログファイルへ明示的にリダイレクトする
cronジョブの実行結果を放置すると、出力内容がroot宛にメールで送信される仕組みになっています。MAILTO=""を設定した上で、標準出力・標準エラー出力をそれぞれログファイルへ明示的に流してください。# 出力を分けてログに記録する例 0 2 * * * /scripts/backup.sh >> /var/log/backup.log 2>> /var/log/backup_err.log # ログが不要な場合（エラーも捨てる） 0 2 * * * /scripts/backup.sh > /dev/null 2>&1
まとめ
深夜のサーバー暴走は、「0」を「*」にした1文字ミスから始まりました。cronは一度設定すると動き続けるため、「慣れているから大丈夫」という油断が最も危ない仕組みです。| ミスの原因 | 防ぐための鉄則 |
|---|---|
| 時刻フィールドの1文字ミス | 変更後はcrontab -lで必ず表示確認 |
| 動作確認の省略 | 本番投入前に手動実行でスクリプトを検証 |
| 出力先の未設定 | MAILTO=""＋ログファイルへのリダイレクトを設定 |
| cron環境変数の相違 | crontabにSHELLとPATHを明示的に記述 |
本番サーバー作業で事故を防ぐ確認習慣の全体像については「Linuxの本番サーバー作業でヒヤリハットした経験談｜現役講師が20年で学んだ事故を防ぐ3つの確認習慣」も参考にしてください。権限設定のトラブルについては「Linuxの本番サーバーでchmodを間違えた話｜現役講師が語る権限ミスの実体験と正しいパーミッション設計の考え方」で詳しく解説しています。
本番サーバーのcron設定で自信を持てる「本物のLinux力」を身につけませんか？
「cronを設定したが本当に動くか不安」という方が多いです。現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxで初めてWebサーバーを公開した日の話｜現役講師が語るApacheが動いた瞬間の衝撃と3つの教訓
- 前のページへ：Linuxを初めて後輩に教えることになった日の話｜現役講師が語る「教える側」に立つ前の不安と、教えることで理解が3段階深まった経験
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます