novox/hq
6
0
Fork 0
Code Issues Pull Requests 6 Releases Wiki Activity

ADR 0269: the catch-up happens when the timer's last run is more than a week back
mesh/merge-gate pass: the change touches no module of the mesh's graph
Details
mesh/repo-check pass: its merge-check.sh passed
Details
mesh/delivery superseded: a newer head of the same pull request
Details

Browse Source
This commit is contained in:
jochen
2026-10-09 01:54:51 +02:00
parent 2e2be955e9
commit 61ab74c70e
1 changed files with 3 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
02-DECISIONS/0269-what-the-meshs-own-declaration-stopped-is-started-again-when-it-goes.md
+3 -2
View File
@@ -82,8 +82,9 @@ before the mesh came, and the mesh's stopping it was the mesh's doing, which goe
- **A restored timer catches up at once.** A timer with `Persistent=true` that was stopped past its
scheduled time fires as soon as it is started again. On the home server the distribution's weekly scrub
timer is such a timer, and a scrub of its pool took about 46 hours (2026-10-05 00:08 to 2026-10-06
22:06). Unassigning the `zfs` module therefore starts a scrub of about 46 hours, within the hour of
the timer's random delay. Unassign it when that load is acceptable.
22:06). Unassigning the `zfs` module after the timer's last run is more than a week back therefore
starts a scrub of about 46 hours, within the hour of the timer's random delay. Unassign it when that
load is acceptable.
- **Harder:** a unit the mesh stopped and that should *stay* stopped after the module goes (one that
was found running by accident) is now started again. Saying so needs a field on the resource, which
no module needs yet. Until one does, the plan's `restore … started … again` step is where it is seen.