Linuxの停止中に定期処理を逃した：systemdのPersistentで戻せる範囲
停止中の予定を拾うなら、OnCalendarのtimerでPersistent=trueを候補にできます。ただし、止まっていた日数分を一回ずつ処理する仕組みではありません。起動の再開と、未処理データの回収を分けて設計します。
公式資料確認日：。
Persistentが保存するのは、起動の時刻
参照するのはUbuntu 24.04のsystemd 255の仕様です。OnCalendarのtimerが無効だった間に少なくとも一度起動予定があれば、有効化時にサービスを起動します。RandomizedDelaySecがあれば遅れを受けます。OnBootSecなどの単調時刻だけのtimerへ同じ効果を期待しません。
三日止まったら、三日分の成果を別に数える
日次集計を三日停止した想定では、サービスが一度起動しただけで三日分を処理済みにはできません。予定対象日と受け入れた成果の一覧から未処理期間を取り出します。これは設計例であり、実環境の試験結果ではありません。
| 観測するもの | 分かること | 次の行動 |
|---|---|---|
| OnCalendarとPersistent | 停止中の起動予定を拾う条件 | 現行timerと対象版を照合 |
| 実開始時刻 | サービスが起動した時刻 | 予定対象日と分けて記録 |
| 欠落対象日 | 必要な未処理範囲 | 業務側で対象を明示して処理 |
| サービスが既にactive | timerは新たな実行を増やさない | 前回の状態と終了条件を見る |
前回が動いていれば、新しい実行は増えない
公式仕様では対象unitが既にactiveなら、timerはそれを再起動せず動いたままにします。RemainAfterExit=yesで終了後もactiveを保つサービスは、繰返し起動の用途に合うか別に判断します。
過去の送信を全部やり直してよいとはしない
遅れた集計と、期限を過ぎた通知・外部書込みは同じ再開方針にしません。過去分の再送が不要なら欠落として記録し、必要なら対象と重複防止を決めます。タイマーを有効にするだけで成果の正しさは戻りません。
まず非機密の別タスクで再開条件を照合する
本番をわざと止めず、許可された試験用timerと短い処理で、予定・実開始・対象を記録します。VPSを追加する前に、現在の停止理由と必要な期限を確定します。常時稼働が必要な仕事かは、その後の実行場所判断です。
公式資料と、判断例の境界
仕様の根拠は以下の公式資料です。本文の記入例は実測値ではありません。購入・設定変更時は、対象の型番・版・契約条件を照合します。
- Ubuntu：systemd 255のtimer仕様
PersistentはOnCalendarに適用。停止中に少なくとも一度予定があれば再有効化時に起動し、RandomizedDelaySecの遅延を受けます。