- Linuxサーバーで サマータイム（DST） への切り替え時に発生する cron ジョブの不具合を警告する記事
- 毎年2回、日曜の午前2時または3時 にタイムゾーンが変更されることで、cron ジョブが重複実行されたり欠落したりする問題が発生
- 実例として、vixie-cron 環境で 3:00〜3:01 の間のジョブが 1秒間隔で60回繰り返し実行 され、メールの混雑が発生
- 解決策として UTCタイムゾーンの設定、または その時間帯のジョブ回避、さらにより優れた オープンソーススケジューラの開発 を提案
- サーバー運用者や DevOps エンジニアに 時間帯切り替えリスク管理の重要性 を再認識させる事例
サマータイムと cron ジョブの衝突
- 日曜の午前2時または3時に cron ジョブを設定すると、サマータイム（DST） の切り替え時点と重なり、予期しない実行エラーが発生
- DST 開始時には時計が1時間進み、終了時には1時間戻るため、時刻の重複または欠落 が発生
- これにより、特定時間帯のジョブが 2回実行されたり、まったく実行されなかったりする問題 が生じる
- 特に毎週日曜の早朝に実行されるジョブは、年2回の DST 切り替え時点 の影響を受ける
- 通常は問題なく動作しても、DST 切り替え日には 異常な繰り返し実行 が発生する可能性がある
実例: vixie-cron の繰り返し実行問題
- Linux 環境の vixie-cron で、DST 開始時に 3:00〜3:01 の間のジョブが 1秒間隔で約60回実行 された事例が報告
- 各ジョブが互いに競合し、メール通知の殺到 のような混乱が発生
- 幸い、そのジョブは致命的なものではなく、システム障害には至らなかった
- この問題は、cron の単純な時刻ベースのスケジューリング構造 に起因する
- cron はタイムゾーン変更や DST 切り替えを認識せず、単純に指定時刻に合わせて実行する
可能な解決策と代替案
- 最も簡単な方法は、日曜の午前2時と3時の時間帯にジョブを設定しないこと
- その時間帯を避ければ、DST 切り替えによる重複実行問題を完全に回避できる
- サーバーのタイムゾーンを UTC に設定 するのも効果的な代替案
- UTC にはサマータイムがないため、時刻変更が発生しない
- より根本的な解決策として、より賢いジョブスケジューラの開発 を提案
- 重複実行防止、実行時間制限、タイムゾーン認識機能などを備えた オープンソースの代替ツール が必要
長期的提案: サマータイム廃止
- 記事の筆者は、政府レベルでの DST 廃止 を最も望ましい解決策として提示
- 毎年2回の時刻変更は、システム運用にも人間の生活にも不要な複雑さをもたらす
- しかし現実的に DST が維持される限り、システム管理者と DevOps エンジニアが予防策 を講じる必要がある
- 特に自動化バッチ処理、バックアップ、ログローテーションなど、時刻依存のジョブ管理 に注意が必要
結論: 安全な cron スケジューリングの原則
- DST 切り替え時点の 2:00〜3:00 の時間帯のジョブは避けるべき
- 可能なら UTC ベースのサーバー運用 でタイムゾーン問題を取り除く
- cron の限界を認識し、より堅牢なスケジューリングツールの導入 を検討する必要がある
- DevOps 環境では、タイムゾーン管理と自動化の信頼性確保 は必須課題
2件のコメント
私も午前2時に設定しておいたジョブで問題が起きて以来（あるときは2回実行され、あるときは実行されない）、必ず避けるようにしています。
Hacker Newsの意見
DST（夏時間） は完全に間違った制度だと思う
何の問題も解決せず、むしろ不便を増やしているだけだ
単に 標準時 に固定して、その代わり勤務時間を夏時間のように1時間前倒しすればよい
たとえば店を7時ではなく6時に開け、10時ではなく9時に閉めるような形だ
どうせ年に2回適応期間があるのだから、1回だけ変えればよい
退勤後にもっと日光を浴びたい。冬は特にそうで、出勤時に日が出ているかどうかは気にしない
どうせ9時間は屋内に閉じ込められるのだから、自由な時間に日光を見たい
たとえば 1973〜1975年の米国における通年DSTの実験 があった
当初は省エネや犯罪減少などの理由で支持が高かったが、
暗い朝の通学路での事故 によって世論が急速に悪化し、結局廃止された
（Wikipediaの引用）
結局は、より大きな時間移動を望んでいるように聞こえる
あるのは標準時と夏時間だけだ
「冬時間を常に維持しよう」という表現は心理的に魅力的ではない
人々は日が出ているうちに一日を始めたいのだ
プログラマーはDSTのせいで苦労するが、それは エッジケース処理 をきちんとやるべき問題だと思う
人によって睡眠パターンは異なるのだから、それぞれに合った勤務時間を選べれば対立は減るはずだ
昔 redditサーバー をセットアップしたとき、全部 Arizona時間帯 に設定していた
ArizonaはDSTを使わないので、カリフォルニアとは1時間差しかない
UTCを使わなかった理由は、ログを読むときに「8を引くより1を引くほうが簡単だから」だった
今はグローバルチームができたのでUTCに変更してある
最初から全部UTCに統一するのがよい
世界中でこうした変更は頻繁に起きるので、カレンダーアプリ開発者の立場では本当に頭が痛い
UTCを選んだならYYYY-MM-DDの24時間表記を理解できると想定すべきだ
組織内で各自がPSTに変更して使っていたため、ログごとに時刻が違うという混乱が起きた
結局リーダーが乗り出して すべてのアプリケーションとDBをPSTに統一 させた
それでも今では本能的にUTCを解釈できるようになった
昔、会社のサーバーを BST（英国夏時間） に設定してcronを多用していたが、
毎年2回 混乱が繰り返された
結局会社が潰れるまで直せなかった
教訓は単純だ — UTCを使え、特別な理由がない限り
たとえば 利用制限のリセット や 請求バッチ処理 は地域時間基準で動く
たとえば英国の8時レポートはDSTによってUTC基準が変わる
したがってUTCだけでは解決せず、タイムゾーン情報も一緒に保存 しなければならない
一部の国（Cuba, Egypt, Lebanon）では DSTの変更が深夜0時に起こる
（関連リンク）
ブラジルでは00:00〜01:00または00:00〜23:00に変わるのが一般的だった
DST調整日には 死亡率と救急外来受診が急増 するという研究がある
（ScienceAlertの記事）
単なるcronの問題を超えて、DSTは 健康にも有害な制度 だ
この問題はずっと前に OpenBSDとDebian ですでに解決されていた
Debianのcron(8)マニュアルには、DST調整時の 3時間未満の時間移動処理ロジック が説明されている
（パッチリンク、
マニュアル、
バグレポート）
深夜0時（00:00） にジョブを予約するなという助言だ
日付が紛らわしくなりやすいので、00:01や01:45のような 中途半端な時刻 を使うのがよい
システムが特定の時刻におかしくなったとき、原因を追跡しやすい
ただし、12時間制の時計を使う環境では混乱が起こりうる
タイムゾーン問題を経験するまでは知らなかったが、
世の中には 存在しない時刻 と 曖昧な時刻 がある
たとえば2時から3時に飛ぶとき、2:30は存在せず、
逆に時間を戻すときには2:30が2回発生する
国ごとにDSTの調整時刻が異なるため、Chileのように深夜0時が消える場合 もある
（関連ブログ）
JavaとRubyがこの状況を異なる形で処理していて、Stripeで働き始めた頃に 3回連続で事故 を起こしたのを覚えている
cronジョブは ちょうどの時刻を避け、できれば 午前4時以降か深夜0時前 に設定している
共有インフラではちょうどの時刻にリソース競合が激しいためだ
sleep $(( $(od -N1 -tuC -An /dev/urandom) % 60 ))m ;のようなコードを付けて 0〜59分のランダム遅延 を与えるのもよい方法だ
重要なスケジュールジョブは、可能な限り idempotent（重複実行に安全） にしておくべきだ
特にキューシステムが絡む場合、この設計が 問題予防の鍵 になる