cron 式パーサー: 任意のスケジュールを平易な英語にデコードします

私が今まで書いた中で最も高価な cron 式は、 0 0 * * 0。, それは私が構築していたLaravel SaaSのための毎週のダイジェストメールを実行しました, そして、私は絶対にそれが意味することを確信していました " 週の最後の日の真夜中. " それは真夜中の日曜日を意味します. 私の精神モデルは、週が土曜日に終了したと述べました. 5 週間, 顧客は、その&quotを得た; レビューで週 " 電子メールは一日遅れ, チームの誰もcronを読むことができませんでしたので、チームの誰もそれをキャッチ - 私たちは皆、ちょうど5 つのフィールドで目を細めてうなずいた。

それが Cron の構文の汚い秘密です。それを書いている人は、半分覚えている前の式からパターンマッチングをしています。 フォーマットは 40 年以上前のもので、1 文字でスケジュールが完全に変更され、静かに失敗します。 「間違った日に実行する」のコンパイラ エラーはありません。誰かが気付くまで、ジョブは、間違った日に実行されます。

あ cron 式パーサー そのギャップを閉じます 式を貼り付けると、実際に何が起こるかを平易な英語で教えてくれます - 0 0 * * 0 " として戻ってくる 00:00, 日曜日" に - プラスいつ次の実行が発火します. そのリードバックステップは、スケジュールを出荷することと推測を出荷することの違いです. Toolz.dev に構築したのは、端末へのコンテキスト切り替えに飽きてしまったためであり、WP Adminify で何年も扱った wp-cron の混乱により、スケジューリング バグがソフトウェアで最も忍耐強いバグであることを教えてくれたからです。

このガイドでは、パーサーの使用方法、5 つのフィールドが実際にどのように機能するか (ほとんどの本番インシデントを引き起こす 2 つの癖を含む)、および cron 構文がどこで異なるかについて説明します クロンタブ、 GitHub Actions 、 Quartz 、 Laravel.

tl;dr: 任意の crontab 式を Toolz.dev Cron パーサー そして、平易な英語翻訳と今後の実行時間を - 即座に、クライアント側、サインアップなしで - 取得します スケジュールをデプロイする前に、常に2 つのことを確認してください: 週の日の番号付け (0 と7 は両方とも日曜日) とスケジューラが実行するタイムゾーン (GitHub Actionsは常にUTC) とペアリングします タイムスタンプ コンバーター 次の実行時間をゾーン間で翻訳する必要がある場合、 日付差分計算 正気度チェック間隔に。

主な機能

平易な英語の翻訳

パーサーの中心的な仕事は、 */15 9-17 * * 1-5 into "Every 15th minutes past hour 9, 10, 11, 12, 13, 14, 15, 16, and 17, on monday, tuesday, wednesday, thursday, and friday." It's verbose - it enumerates rather than collapsing "9 through 17" back into a range - and that verbosity is the point.列挙は明白です; 要約された範囲は、読み間違えるもう一つのチャンスです 文は、プルリクエストの説明に貼り付けたり、スタンドアップで読み上げたり、非技術的な利害関係者を表示したりできるものです 生表現はそうではありません 私の経験では、翻訳が最も重要です コードレビュー中に: 5 つの不可解なフィールドをゴム印するレビュアーはすぐにキャッチ " wait, なぜ時間17 が現れるのか ジョブが5 PMで停止することになっているとき?" 時間ごとに綴られるとき 翻訳はスケジュールを改ざん可能にします これはまさに生のcron構文が失敗することです。

次の実行プレビュー

どんな表現か知っている という意味 問題の半分です。いつ問題になるかを知っています 次は火事 は残りの半分です.パーサーは,次の5 回の実行回数を計算して,あなたの意図にそってそれらを照準できる.これは微妙な間違いが表面化する場所である. - これは英語でうまく読めるが,次回実行の " を生成する式である.in 27 days" day-of-month を月と混同したから,または週末後の 03:00 を意味していた今夜 03:00 に起動する式である.私は,今毎回のように次実行リストをチェックする,たとえ式 I' に自信がある.特に式 I' に自信がある - 冒頭の逸話を見る.

2 つの時間の計算方法についての 2 つの詳細。 まず、それらは評価されます。 お使いのブラウザのローカル タイムゾーン、UTCではなく、あなたのサーバー& #39; sゾーンではありません - 各実行は2 回表示され、1 回はローカルタイムスタンプとして、1 回は同等のUTCインスタントとして表示されるため、展開目標に一致するものを読み取ることができます2 番目に、月日と週日の両方が制限されている場合、パーサーはANDではなく実際のcron& #39; sまたはセマンティクスを適用します: 0 0 1 * 1 月の1日に火災 あんど 毎週月曜日、1 日の月曜日だけでなく、 そのルールは経験豊富な人々をつまずかせ、具体的な日付を 5 つ見ると、文章では決してできない方法でそれが明らかになります。

1 つのラフ エッジ: 不可能な表現のような 0 0 30 2 * (2月30 日) は、有効として解析し、それ自体を喜んで " として説明し、2 月の30 の日の00:00 に、 " そして、空の次の実行リストを示す。 emptyは決して意味しない。 It' s correct, but it' s quiet - a " このスケジュールは決してfire" will never will fire" warning is the obvious improvement and I haven't built it yet.

フィールドごとの内訳

パーサーは式をその 5 つのコンポーネント (分、時間、月、月、曜日) に分割し、それぞれが貢献するものを示します。 cron エラーはほとんどの場合、単一フィールドの問題、つまり間違った列の正しい値であるため、これは重要です。 0 12 * * * (毎日正午) と 12 0 * * * (毎日12:12 AM... いいえ、毎日 00:12) 1 回の交換でおかわりします。 「時間: 0」のラベルが明示的に表示されるのは、2 週間ではなく 2 秒でスワップをキャッチする方法です。

範囲、ステップ、およびリストのサポート

実世界の式は、演算子の構文に大きく依存します。 1-5 範囲、 */10 ステップ、 1,15 リスト、および次のような組み合わせ 0 8-18/2 * * 1,3,5.パーサーは、人間の読者をつまずかせる結合形式を含む、そのすべてを処理します。 step values over ranges - 8-18/2 意味 " 2 時間おきに 8 から 18" - 合法で便利で、ツールなしでほとんど読めない。 you' がこれらの完全なクロンタブを離れたシステム管理者から継承したことがある場合は、この機能が存在する理由がわかります。

厳密な 5 フィールド検証 (受け入れられないものを含む)

パーサーは、標準の 5 フィールド式を取ります。他には何もありません。 貼って @daily そして、あなたはエラーを取得します - " 予想5 フィールド (分時間月日月日週日), 1" を取得しました - 翻訳ではありません。 に同じ @hourly、 @weekly、そして @reboot。 これは、設計原則ではなく真のギャップであり、デバッグの途中で分かるようにするよりも、ショートハンド マクロは実際の crontab でツールに属している場合に十分に一般的です。 入るまでは、手動で翻訳します。 @hourly です 0 * * * *、 @daily です 0 0 * * *、 @weekly です 0 0 * * 0、 @monthly です 0 0 1 * *、 @yearly です 0 0 1 1 *。 @reboot 5 フィールドに相当するものはまったくありません。それは isn'スケジュールではなく、デーモンの起動時に 1 回実行されます。この事実は、crontab からの移行を実行している多くの人々を驚かせました。

厳格さは他の場所で報われます。 6 フィールドのクォーツ式は、黙って読み込まれるのではなく、フィールド カウントで拒否されます。 範囲外の値のフィールドと法定範囲の名前を指定します (Value 25 out of range for hour (allowed 0-23). 逆の範囲 5-1 捕まります。 そして、実際の crontabs に含まれるものを受け入れます: 月と日の名前 (JAN、 SUN、) 7 日曜日の 2 番目のスペルとして、そしてビクシー 5/15 フォームは、「15 度ごとに 5」を意味します。 マクロを手作業で翻訳している間は知っておく価値があります。 @daily サーバー上のジョブは同じ瞬間、つまり真夜中に起動するため、そのうちの 40 個は毎晩のロード スパイクになります。私は私のものを奇数分に散らばらせます()17 3 * * *、 43 4 * * *) まさにそのためです。

クライアント側の処理

パーサーは完全にブラウザで実行されます。 貼り付けたものは何もアップロード、ログ、または保存されません。 これは、Crontab に実際に含まれるものを覚えるまでは、ボイラープレートのプライバシーのように聞こえます。バックアップ スケジュール、請求の実行タイミング、セキュリティ スキャンが起動した正確な時間です。 インフラストラクチャのスケジューリングは、偵察データです。 他の人のサーバーから離れることは、偏執的ではありません。ただ、何も存在しない必要があるという問題を引き起こすわけではありません。

cron パーサーの使い方

ステップ 1: 式を貼り付けまたは入力する

を開きます クロンパーサー そして式をドロップします - crontab ファイルから、a schedule: GitHub アクション ワークフローでのブロック、Kubernetes CronJob マニフェスト、または Laravel のブロック ->cron() 電話してください。 標準の 5 フィールドの構文はそのまま動作します。 @daily そして、その兄弟はそうではないので、最初にそれらを 5 つのフィールドに展開します。 次に、解析を押します。 デコードではなくゼロから始めている場合は、プリセット ボタン (毎分、時間単位、毎日、午前 9 時、平日午前 9 時、月の 1 日) 作業式をフィールドごとに変更して、フィールドごとに再解析できます。

ステップ 2: 翻訳を読み返す

これはステップです 人々はスキップし、should& #39; t. plain-English の出力を読み、頭の中の文と比較します。 " を意図する表現を書いた場合毎週月曜日 9 AM" とリードバックは " 月曜日の 09:00 に 1" - おめでとうございます。生産前に古典的な列交換をキャッチしたばかりです。リードバックは単体テストです。

ステップ 3: 次の実行時間を確認する

今後の5 つの処刑を確認してください 日付はあなたが期待する場所に着地しますか? 最初の実行は今夜、明日、または来月ですか?実行間のギャップに注意を払う - 置き忘れ */ ステップは、「6 時間ごと」に「6 時間ごとの毎分」に変わります (* */6 * * * vs 0 */6 * * *)、そして 5 ランを 6 時間間隔ではなく 1 分間隔で走らせるのは見逃せません。 リストが空の場合、スケジュールは決して起動できません。

ステップ 4: 展開前のタイムゾーンのアカウント

パーサーが教えてくれる いつですか 時計に関連して、スケジューラーが決定します 誰の 時計。 展開する前に、実行システムが使用するタイムゾーンを確認してください。 GitHub アクション: 常に UTC で、例外はありません。 サーバー: OS が設定されているものは何でも、多くの場合、クラウド ボックスで UTC を使用します。 Laravel: 連鎖しない限り、アプリのタイムゾーン ->timezone()。 次の実行時間を、 タイムスタンプ コンバーター 地元のゾーンまたは顧客で見る必要がある場合。

テクニカル ディープ ダイブ: Cron 式が実際にどのように機能するか

5 フィールド形式は Unix cron に由来しており、1980 年代後半に Paul Vixie's cron 実装によって実際に標準化されました。これは、に文書化されています crontab(5) そして、今日のほとんどの Linux システムでは、まだ子孫の形で出荷されています。 フィールド、左から右:

各フィールドが受け入れる * (任意の値)、リスト (1,15)、範囲 (1-5)、および手順 (*/10 や 20-59/5)。それと#39;文法全体。構文の複雑さは isn't - it's 3 つの動作の癖。

Quirk One: 曜日ゼロ。 につき crontab(5)、0 と 7 はどちらも日曜日を意味する。 幾つかの古い、あるいはより厳格な実装は 0 のみを受け入れる。 Quartz - Jenkins とエンタープライズソフトウェアの半分が使用する Java スケジューラ - は、 から始まる 1 日 ~ 7 日を数える 日曜、クォーツです 2 月曜日ですが、crontab's です 2 火曜日です。 システム間でスケジュールを移行したことがある場合、これは 1 つでも待たされています。 常に解析し、決して書き起こさないでください。

クォーク 2: 月の日または曜日。 これは、噛むまでほとんど誰も知らないものです。 いつですか 両方 月の日と曜日のフィールドは制限されています (どちらも *)、Vixie Cron がジョブを実行するとき どちらか 一致 - AND ではなく OR です。それで 0 0 13 * 5 「13 日の金曜日」という意味ではありません。「毎月 13 日と毎週金曜日」という意味です。これは、文書化された動作です。 crontab(5) そして、それは非常に直感に反しています。 「13 日の金曜日」が本当に必要な場合は、スクリプトサイドの日付チェックまたはより豊富な構文のスケジューラが必要です。

クィーク 3: タイムゾーンと DST。 Cron にはタイムゾーン フィールドがありません。 式は、スケジューラーの現地時間で解釈されます。 2 つの具体的な結果:

• GitHub アクションが実行されます schedule: UTC でトリガー、完全停止。 でスケジュールされたワークフロー 0 9 * * * 季節に応じて、ニューヨークでは午前 9 時 (UTC) に火災が発生します。UTC は DST を観察しますが、対象のオーディエンスと #39; 時計は観察するからです。あなたの "午前 9 時の日報と引用;ワークフローを調整するかコードで処理しない限り、年に 2 回 1 時間ずつドリフトします。
• DST を観測するゾーンに設定されたサーバーでは、年 1 晩、02:00 ～ 03:00 の時間が存在せず、1 晩は 2 回発生します。 02:30 に予定されているジョブは、実装に応じてスキップまたはダブルファイアします。 退屈で正しい修正: 01:00 ～ 03:00 ローカル以外の重要なジョブをスケジュールするか、UTC でサーバーを実行します。 私は両方をします。

拡張フォーマット。 Quartz は 6 つまたは 7 つのフィールド (先頭の秒フィールドとオプションの末尾の年) と、次のような追加の演算子を使用します。 L (最後)、 W (最も近い平日)、そして # (第 1 平日). cron の中には先頭秒フィールドもサポートするものもあります.もしあなたの式に 6 つのフィールドがあり, you' どの方言かよくわからない場合は,それをパーサに貼り付けます - 5 フィールドと解釈される 6 フィールド式は,目に見えて間違った出力を生成します.それ自体が診断になります.そして @reboot特別な文字列の奇妙なアヒルは、まったくスケジュールではありません。デーモンの起動時に 1 回実行されます。これは、最新のシステムでは、「ボックスが再起動するたびに」を意味します。これは、CrontAb から多くの人がデータベース移行を実行しているのを驚かせました。

スケジュール作業とペアになる開発者ユーティリティの広範なツアーでは、 コーディング ツール ガイド ツールボックス全体をカバーします。

よくある使用例

Laravel スケジューラ エントリのデバッグ

Laravel' sスケジューラは流暢なメソッドでcronをラップする - ->dailyAt('03:00')、 ->weeklyOn(1, '8:00')ーでも脱出ハッチは、 ->cron('*/5 * * * 1-5')、は生の crontab 構文であり、複雑なスケジュールがそこに終わります。 システムの crontab が実行されます schedule:run 毎分、Laravel は、期限内に何をするかを内部的に決定します。 スケジュールされたコマンドが起動しない場合、最初の動きは、 ->cron() パーサーに文字列を入力して、上記のコメントが主張することを確認します。 半分くらいの時間ですが、そうではありません。 残りの半分は、タイムゾーンです。アプリは次のように設定されています。 UTC 開発者が現地時間と仮定している間。 パーサーは最初のケースを数秒で解決し、2 番目のケースを指差します。

WordPress サイトで WP-Cron を解きほぐす

WordPress には wp-cron が同梱されており、これはページ訪問に便乗する疑似スケジューラーです。そのため、トラフィックの少ないサイト's "hourly" job は 4 時間ごとに実行され、トラフィックの多いサイトではすべてのリクエストに少額の税金がかかります。私の WP 管理年中、これにより "scheduled posts aren't publishing" reports が安定して発生しました。標準の修正は wp-cron を無効にする ()DISABLE_WP_CRON) とトリガー wp-cron.php 実際のサーバー crontab から - その時点で you'通常は実際の cron 式を書き込みます */5 * * * *、そしてパーサーは、それらを検証し続けることを取得します。 WordPress をどの規模でも実行する場合、この移行は、いつかではなく、今週実行する価値があります。

GitHub アクション スケジュールの確認

CI スケジュールは静かに失敗します。実行を停止する毎晩のビルドでは、誰にもページを表示できません。 を書くとき schedule: trigger, I parse the expression, look at the next-run times, then mentally add the UTC offset. Actions に固有の 2 つの追加詳細: schedules はデフォルトのブランチでのみ実行され、実行はハイロード期間中に遅延またはドロップされる可能性があります - GitHub' s 自身のドキュメントでは、正確なタイミングが問題であれば、cron-triggered Actions は間違ったツールとなります; おおよそのタイミングが問題ない場合は、少なくともおおよその時間を the でしょ おおよその時間。

継承された crontab の監査

すべての長寿命のサーバーは、そこではもう働いていない人々が書いた crontab を蓄積します。 走ってる crontab -l そして、パーサーに各行を貼り付けることが、私が知っている中で最も速い監査です。10 分以内に、わかりやすい英語のスケジュール インベントリが作成され、ほとんどの場合、誰も覚えていないことを実行する少なくとも 1 つの仕事が見つかります。つまり、バックアップが 2 回実行され、クリーンアップ スクリプトが実行されました。予定されていた日に決して一致しませんでした * * * * * あったはず 0 * * * * 1 時間に 60 回 API を打ちます。 移行中に古い crontab と新しい crontab を比較すると、 テキスト差分ツール パーサーと並んで、レビューを機械化します。

スケジュールを立てる Kubernetes CronJobs

K8S CronJob は、標準の 5 フィールド構文を使用し、1.27 以降、明示的な timeZone フィールド - クラシック cron に対する真正な改善です。 parser ワークフローは同じです: 式を検証し、次の実行を確認してから確認します startingDeadlineSeconds あんど concurrencyPolicy 故障モードをカバーする Cron 自体はそうではありません。 式は完璧で、ゆっくりとした実行が次のトリガーと重なる場合でも、ジョブは積み重なっていきます。パーサーはスケジュールを正しく取得するため、代わりにこれらの操作設定に注意を払うことができます。

クロン方言と比較

いつ使うか: プレーンサーバージョブ用の crontab、最新の Linux で無料でログ記録と依存関係の処理を行いたい場合の systemd タイマー、とにかくジョブがアプリ内に存在する場合の framework スケジューラー、および Actions スケジュールはファジーなタイミングを許容する CI タスクのみを選択する方、5 フィールド式は共通語です - そのため、それを流暢に話すパーサーはブックマークの残りの部分の隣に属します Web 開発者ツールキット。

フェイク

cron 式パーサーとは何ですか?

cron 式パーサーは、crontab 構文を読み取るツールです */15 9-17 * * 1-5- そして、通常は次の実行時間のプレビューと並行して、それを平易な英語のスケジュール説明に変換します。これにより、本番環境でのジョブの起動時に誤読フィールドを発見するのではなく、スケジュールを展開する前にスケジュールが実際に何を行うかを検証できます。

cron 式の 5 つのフィールドは何を意味しますか?

左から右へ: 分 (0 ～ 59)、時間 (0 ～ 23)、月 (1 ～ 31)、月 (1 ～ 12)、および週の日 (0 ～ 7、0 と 7 の両方が日曜日を意味します)。 各フィールドが受け入れる * 任意の値の場合、カンマ リスト、ハイフン範囲、 / ステップ値。 そー 30 2 1 * * は、毎月 1 日の 02:30 を意味します。

cron ジョブが間違ったタイミングで実行されるのはなぜですか?

最も一般的な原因は、タイムゾーンとフィールドの混乱の 2 つです。 cron はスケジューラーで実行されます' s 現地時間 - GitHub アクションは常に UTC を使用し、多くのクラウド サーバーでも使用します - そのため、"9 AM" にスケジュールされたジョブは、ウォール クロックから数時間オフに表示される可能性があります。もう 1 つの定番は、分列に時間値を入れるなどのフィールドの交換です。式を解析し、次の実行時間をチェックすると、両方が検出されます。

0 と 7 はどちらも日曜日に Cron で?

Vixie cron およびほとんどの Linux 実装では、はい、 crontab(5) man ページでは、日曜日に 0 と 7 の両方を許可します。 しかし、これは普遍的ではありません。クォーツは日曜日から 1 ～ 7 日目で、厳密なパーサーの中には 7 を拒否します。 システム間で式を移動する場合は、番号が引き継がれると仮定するのではなく、曜日フィールドを再確認してください。

何が 0 0 13 * 5 実際にしますか？

「13 日の金曜日」ではありません。月の日と曜日の両方が制限されている場合、標準の cron はそれらを OR として扱います。ジョブは月の 13 日ごとに実行されます。 あんど 毎週金曜日。 これは、Vixie Cron の動作を文書化しており、最も誤解されている形式のルールの 1 つです。 true が必要な場合は、スクリプト自体に日付チェックを追加します。

サマータイムは Cron ジョブにどのように影響しますか?

DST を観察するタイムゾーンのサーバーでは、現地時間の 01:00 から 3:00 の間にスケジュールされたジョブは、実行をスキップ (クロックがジャンプする場合) または 2 回 (後退した場合) に実行できます。 最も安全なパターンは、UTC でサーバーを実行するか、そのウィンドウの外で重要なジョブをスケジュールすることです。 GitHub アクションのような UTC ベースのスケジューラは実行をスキップしませんが、それらが 1 年に 2 時間シフトに対応する現地時間に注意してください。

です @daily と同じ 0 0 * * *?

はい - @daily (そしてその同義語 @midnight) は正確に展開します 0 0 * * * ビクシークロンで。 2 つの注意事項。 まず、Toolz.dev パーサーは 5 つのフィールド式しか受け付けないので、貼り付けます 0 0 * * * というより @daily とりあえず。 第二に、毎回 @daily ジョブは同時に発生するため、多くのサーバーが真夜中の負荷を増やします。 日々の仕事を、ずらした時間にかけて分散させることで、自らの雷鳴のような群れを回避できます。

Toolz.dev Cron パーサーは私の式をアップロードしますか?

いやー . クロンパーサー 完全にブラウザー内で実行されます - 式はクライアント側で解析され、サーバーに送信されたり、ログに記録されたり、保存されたりすることはありません。 crontabs はバックアップのタイミングや請求の実行などの運用詳細を明らかにするため、サードパーティのサーバーからそれらを遠ざけるのは賢明なデフォルトであり、ブラウザーで動作を自分で確認できます 's ネットワークタブ。

発送する前に読み返してください

5 週間ダイジェストメールの1 日遅れ到着は劇的な停止ではありません.Nobody paged me. That's exactly what makes scheduling bugs expensive: they don't announce themselves, they just quietly do the wrong thing until a customer mentions it in passing.私のためにそれを修正した習慣 isn't discipline or a better memory for field order - it's a thirty-second readback.式を貼り付け、英語の文を読み、5 つの具体的な日付を見てから展開します。

を保持します クロンパーサー 同じデバッグ セッションで、あなたがたどり着くツールの横にあるもの: タイムスタンプ コンバーター 次の実行時間は、ゾーン間で移動する必要がある場合 (私は、 UNIX タイムスタンプ トラップ それは一番辛いものです。 日付差分計算 正気度チェック間隔、および テキスト差分ツール 移行中に古い crontab と新しい crontab を比較している場合。 ザ・ コーディング ツール ガイド セットがどのように組み合わされるかを説明し、すべてがクライアント側で実行されます。バックアップと請求がいつ実行されるかを正確に文書化するファイルにとって、これが唯一の賢明なデフォルトです。