小さなスケジュールジョブに明確な境界を与える。

1つの有限な作業を定義する

既存のレコードから小さな日次サマリーを再構築する個人ツールを想像してください。ジョブは範囲が限定されたデータを読み取り、1つの置換サマリーを準備して終了します。これはWebサーバーではなく、スケジュールされた開始の間に実行し続けるべきではありません。タイマーを追加する前に、入力、宛先、予想所要時間、成功とみなす条件を書き留めてください。

この例では、systemdとutil-linuxを備えた Linux ホストを前提としています。 flock、管理者アクセス、および既存の非特権アカウントとグループ名 fieldjob。そのレビュー済みジョブスクリプトは次にあり、 /opt/field-jobs/build-summary フォアグラウンドで実行されます。管理者がそのスクリプトを所有し、ジョブアカウントは読み取りと実行はできますが、コードを書き換えることはできません。お使いのディストリビューションで実行可能ファイルのパスを確認してください。これらはテンプレートであり、インストールされた OffVPS スケジューリングサービスではありません。

スクリプトはゼロ以外の終了ステータスで失敗を報告する必要があります。置換ファイルの場合、公開前に一時的な結果を準備して確認するように設計してください。データベース作業の場合、データベースのトランザクションまたは重複排除メカニズムを使用してください。ロックだけでは、部分的に完了したタスクを安全に繰り返すことはできません。

タイムゾーンと実行漏れポリシーを選択する

私たちのサマリーは、UTC 02:15 に1日1回役立ちます。マシンのローカルタイムゾーンが見えない依存関係にならないように、明示的なゾーンを使用してください。この例ではUTCが季節的な時計変更を避けます。ローカル市民時間に結びついたビジネスタスクには、名前付きタイムゾーンと夏時間動作のレビューが必要です。 systemd 時間リファレンス はカレンダー式を説明しています。

このテンプレートを次として保存してください: /etc/systemd/system/field-summary.timer 名前を確認した後、意図したVPS上で:

[Unit]
Description=Daily personal-tool summary

[Timer]
OnCalendar=*-*-* 02:15:00 UTC
Persistent=true
Unit=field-summary.service

[Install]
WantedBy=timers.target

Persistent=true カレンダーイベントが見逃された場合、非アクティブ期間後のキャッチアップアクティベーションを要求します。見逃された日ごとに別の実行を再生するわけではありません。また、タイマーはそのサービスがアクティブな間に同じサービスの別のインスタンスを開始しません。これらの動作とスケジューリング精度は、次で説明されています: タイマーリファレンス。キャッチアップを有効にする前に、遅れたサマリーが有用かどうかを判断してください。

サービスユーザー、状態ディレクトリ、ロックを設定する

対応する /etc/systemd/system/field-summary.service は作業を説明します:

[Unit]
Description=Build the personal-tool summary

[Service]
Type=oneshot
User=fieldjob
Group=fieldjob
WorkingDirectory=/opt/field-jobs
StateDirectory=field-summary
StateDirectoryMode=0700
UMask=0077
ExecStart=/usr/bin/flock --nonblock --conflict-exit-code 75 /var/lib/field-summary/job.lock /opt/field-jobs/build-summary
TimeoutStartSec=5min
StandardOutput=journal
StandardError=journal

Type=oneshot 完了するコマンドに適しています。明示的な起動タイムアウトがこの例を制限します。各実行後に非アクティブになる必要があるサービスに RemainAfterExit=yes を追加しないでください。参照: systemdのサービスセマンティクス。ワークロードからタイムアウトを設定し、5分がすべてのジョブに合うと仮定するのではなく、中断を安全にしてください。

このシステムサービスの場合、 StateDirectory は指定されたディレクトリを次に作成します: /var/lib サービス所有権付き。作業ディレクトリ、ユーザー、権限、出力先は明示的です。スクリプトは自身のツールとデータに絶対パスを使用するべきです。環境とディレクトリのルールは次で文書化されています: systemdの実行リファレンス。コマンドライン引数に秘密の値を入れず、ログにも記録しないでください。

非ブロッキング flock ラッパーは、別の協調する呼び出しがこのロックを保持している場合、コード 75 で終了します。私たちは意図的にそれを、スキップされたサマリーを完了した作業として扱うのではなく、レビューが必要な可視的な失敗として残します。すべての手動呼び出しは同じラッパーとロックパスを使用する必要があります。実行中のジョブを解放するためにロックファイルを削除しないでください。新しいファイルは別のロックを作成する可能性があります。これはローカルファイルシステムのパターンであり、VPSインスタンス間の分散ロックではありません。参照: upstream flock マニュアル.

ファイルを確認し、制御された1回の実行を試す

最初の実行では、送信メール、支払い、その他の副作用を無効にした使い捨てデータセットを使用してください。アクティベーション前に、そのテストホストで解析されたスケジュールとユニットファイルを検査してください:

systemd-analyze calendar '*-*-* 02:15:00 UTC'
systemd-analyze verify /etc/systemd/system/field-summary.service /etc/systemd/system/field-summary.timer

これらのチェックはユニットとスケジュールの間違いを捕まえることができますが、スクリプトが正しいサマリーを生成することは証明できません。 systemd-analyze リファレンス はその範囲を説明しています。エラーを修正した後、レビュー済みのファイルをロードし、テストジョブを明示的に開始してください:

sudo systemctl daemon-reload &&
  sudo systemctl start field-summary.service
systemctl status field-summary.service --no-pager
sudo journalctl -u field-summary.service --since "10 minutes ago" --no-pager

有限回の成功した呼び出しと、確認済みの出力成果物を期待します。成功した oneshot はその後 inactive と表示される場合があります。空入力時の挙動を含め、結果そのものを検査してください。テスト専用の実行を意図的に遅くし、同じロックされたコマンドをテストデータセットに対して2回呼び出し、2回目の呼び出しが競合する結果を書き込まずにロック競合を報告することを検証してください。

出力を確認した後にのみスケジュールを有効にする

sudo systemctl enable --now field-summary.timer
systemctl list-timers field-summary.timer --all

次回のスケジュール時刻を確認し、その後最初のスケジュール結果を確認します。開始時刻、終了時刻、処理件数、結果をスクリプトのログに記録してください。成功記録が無いことは検査する理由であり、ジョブが実行された証拠ではありません。参照: systemctl の timer および activation コマンド.

将来の起動を一時停止するには、次を使用します: sudo systemctl disable --now field-summary.timer。これはすでに実行中のサービスを終了しません。中断が必要な場合は、まず現在の書き込みを安全に停止できるか確認してください。作業が増えるにつれ、所要時間、再試行、外部 API の制限を確認してください。複数のマシンでは共有された調整が必要です。次を続けてください: 個人向けツールのシナリオ および リストア演習 この自動化が維持するデータ向け。