開発者ツール · Crontab ジェネレーター
anacron と cron.daily: スケジュールされたジョブがマシンの電源がオフになっても存続する方法
· 背景
クロン 信頼性 スケジュール設定
cron はマシンが常にオンであることを前提としています。アナクロンはそうではありません。この投稿では、anacron が最後の実行を追跡する方法、Debian スタイルの cron.daily ディレクトリがそれをどのように使用するか、および 2 つのうちのどちらかを選択する方法について説明します。
スリープ マシンのシナリオはブラウザの外部にあります。プレビューは将来の候補のみを検索します
ToolAcre は、ラップトップが 06:25 を通じてスリープしたかどうかを観察できません。その次回実行関数は開始瞬間を受け取り、1 分後に開始して厳密に前方検索を行います。この機能は履歴エンジンや回復エンジンではなく将来のプレビューであるため、以前の一致する分は返されません。
そのため、このリストは計画には役立ちますが、後追いについては考慮されていません。失われた過去の候補者は、実行されたか、スキップされたか、別のサービスによって処理された可能性があります。ブラウザには実行記録がありません。将来のみのリスト内の不在からではなく、インストールされているスケジューラーからダウンタイムの動作を診断します。
外部 cron の実行ミス動作はここでは確立されていません
ワークブックは、cron が見逃した分を破棄すると主張しました。このリポジトリにはデーモン実装や稼働時間テストは含まれないため、普遍的な主張は繰り返しません。証明されているのは、ToolAcre 自体はジョブをキューに入れず、メモリ内の日付を計算してページに返すということです。
ターゲット スケジューラは実行ミス ポリシーを文書化することができ、ラッパーは別のポリシーを追加することができます。そのポリシーを明示的にキャプチャします。同じ `0 6 * * *` 式は、その 5 つの値を変更せずに、さまざまなリカバリ設計に参加できます。
anacron 状態と遅延は実装されていません
`cron.js` には、anacron タイムスタンプ ファイル、期間カウンター、起動遅延はありません。パーサーはカレンダー フィールドを認識し、プレビューは設定可能な検索範囲を認識します。どちらも、外部アクションが最後に完了した時期を保存しません。
したがって、この記事では、プロジェクトの証拠に基づいて anacron の正確な状態遷移を説明することはできません。キャッチアップが必要な場合は、実際の施設を調査してテストします。 ToolAcre は、同時に保持されている正確な時間の cron 行を構築できますが、anacron ポリシーを検証することはできません。
anacrontab 構文は 5 フィールド パーサーの範囲外です
anacrontab 行は 5 フィールドの cron 式ではありません。実際の構文について何も教えずに、その期間、遅延、識別子を ToolAcre にフィードすると、フィールド数または値の検証に失敗します。同様のスケジュール目標は、交換可能なファイル形式を意味するものではありません。
ネイティブのバリデーターをネイティブの文法で保持します。このルートは分から平日までの式に使用し、期間ベースのキャッチアップ構成には別のソースを使用します。翻訳では、単に 1 つのテキスト形式を別のパーサーに強制するのではなく、操作上の要件を維持する必要があります。
cron.daily の配線はこのリポジトリから推測できません
ディレクトリ メカニズムとパッケージ間のハンドオフは、レビュー中のコードベースにはありません。ジェネレーターは、`/etc/cron.daily` が存在するかどうか、どのランナーがそれを呼び出すか、別のパッケージがインストールされたときに何が起こるかを知ることができません。このような配線は環境固有の証拠となります。
タスクを移動する前にターゲットをインベントリします。ディレクトリ名だけでは実時間や追いつき動作を明らかにすることはできません。観察されたサービス構成を要件と比較し、ジョブが互換性のある cron パスに実際に残っている場合にのみ ToolAcre 式を保持します。
作業境界: キャッチアップを約束せずに将来の候補を比較します
日次の例の場合は、`0 6 * * *` と入力し、展開ゾーンを選択します。プレビューには、今後の 06:00 の壁時計の候補が最大 5 つリストされます。開始時点がすでに今日の 06:00 を過ぎている場合、明日が最初の結果になります。それは前方検索の動作であり、今朝起こったことの証拠ではありません。
リストを使用して、カレンダーの意図とゾーン変換を確認します。次に、スケジュールされた時間にわたって安全なテスト環境の電源を入れ直すか一時停止し、実際のスケジューラーのポリシーを観察します。 2 つの実験は異なる疑問に答えるものであり、別々に記録しておく必要があります。
永続タイマーの動作は未検証のため省略されています
ワークブックには、別のサービス マネージャーの永続的な設定が記載されています。ここでは、そのステートメントをサポートするユニット パーサーやテストはありません。関連する外部調査である可能性がありますが、このモジュールは信頼できる情報源がない限り、それを推奨事項にはしません。
実行ミスの要件には、直ちに実行するか、スキップするか、合体するか、すべての発生を保存するかという、明示的な受け入れ基準が必要です。必要な結果を文書化するシステムを選択し、それを検証します。 ToolAcre が提供できるのは、ベースラインとして使用される cron の頻度だけです。
要点: スケジュールと個別に検証された実行ミス ポリシーを組み合わせる
マシンが使用できない可能性がある場合、繰り返し式は信頼性設計としては不完全です。カレンダーのマッチングとキャッチアップ ポリシーは別のものです。 ToolAcre は前者を公開し、後者の実行状態を意図的に保持しません。
将来をプレビューし、ゾーンを記録して、宛先での未実行動作をテストします。別のメカニズムがリカバリを所有している場合は、式の横にそれを文書化します。ジェネレーターまたは 5 つのフィールドが再試行を保証すると言うことは避けてください。どちらも実行が失敗したことを確認できないからです。