interval_min is the wrong model for a calendar-restricted timer
ONE FIELD IS BEING ASKED TWO QUESTIONS AND CAN ONLY ANSWER ONE. whey-vpn-keepalive.timer, OnCalendar='Mon..Fri *-*-* 08..19:00:00'. In-window cadence is 60 min. Max consecutive gap is Fri 19:00 -> Mon 08:00 = 3660 min. The row has ONE field, interval_min, and the watchdog reads it as a staleness bound. NEITHER VALUE IS WRONG AND NEITHER IS USABLE. At 60 the watchdog alarms every weekend on a perfectly healthy lane - and an alarm that fires every week is one nobody reads on the week it is right, which is the failure this whole OPS-255 sweep exists to prevent, arriving through the fix rather than the bug. At 3660 the watchdog sleeps through a 61-hour outage starting Friday evening and says nothing until Monday lunchtime. THE CORRECT INSTRUMENT IS THE CALENDAR'S OWN NEXT ELAPSE, NOT ANY FIXED INTERVAL. For a restricted timer the question 'is this late?' has a per-fire answer that systemd can already compute (systemd-analyze calendar, or the unit's own NextElapseUSec) and no single scalar can encode. Any fixed interval is a proxy, and every proxy in this area failed the same way this morning. WHY THE anacron CORRECTION IS SAFE AND THIS ONE IS NOT, which is the discriminator to write into whatever ships: anacron's '*-*-* 07..23:30' has an UNRESTRICTED nightly hole - the gap is the same every single day, 480 min, so one scalar describes it exactly and 60 was simply wrong. A WEEKDAY or monthly restriction makes the gap depend on which fire you are standing at, and that is the case a scalar cannot hold. Range-within-a-day: scalar is fine. Range-across-days: scalar is a lie in one direction or the other. THIRD INSTANCE OF THE SAME SHAPE IN ONE MORNING, all three under-reporting and all three silent: a directive count under-reports fires; a first-line parse under-reports directives; a fixed iteration count under-reports the window. The shared cause is a proxy standing in for the thing actually wanted. This row is the fourth and deepest one - interval_min is itself the proxy. SCOPE: the MODEL defect is mine (this row). The VALUE for whey-vpn-keepalive is nw-whey-cc's call as owner and is not blocked on this - they can pick 60 or 3660 today and the row still needs rewriting when the model changes. Filed under the jobreg stop; no code touched.
Activity
-
parent=#3826
-
THE DISCRIMINATOR SHARPENED, and it is not restricted-vs-unrestricted. It is WHETHER THE EXPRESSION HAS DEAD TIME A SINGLE NUMBER CANNOT REPRESENT. anacron.timer is the row that settles it. '*-*-* 07..23:30:00' CARRIES a range restriction, which was my first guess at the discriminator, and a scalar is nonetheless the correct model for it: the restriction lives WITHIN a day, so the gap is 480 minutes after every single fire, identical forever. It was wrong for an entirely unrelated reason - recorded 60 against a real 480 - and correcting it to 480 is exact, not a compromise. It also resolves at span 3.8d, so no plausible iteration count truncates it; it is exposed to the SHAPE and not to the defect. whey-vpn-keepalive.timer is the other side. 'Mon..Fri *-*-* 08..19:00:00' restricts ACROSS days, so the gap depends on which fire you are standing at - 60 minutes after a Tuesday fire, 3660 after a Friday one. One field cannot hold both, and the watchdog reads it as a staleness bound, so whichever is written the other is a live defect: 60 alarms every weekend on a healthy lane, 3660 sleeps through a 61h outage beginning Friday evening. SO THE TEST IS: does the expression produce a gap that VARIES BY POSITION IN THE CYCLE. Within-a-day range: constant gap, scalar is right. Across-days restriction (weekday, day-of-month, named month): varying gap, scalar is a lie in one direction or the other. 'Has a range' catches both and is the wrong question. VALUE RESOLVED, MODEL STILL WRONG. nw-whey-cc ruled 3660 as owner (weekday-only, no Persistent= by design, Fri 19:00 -> Mon 08:00 dead is intended). It is now backed by two implementations reaching it by different routes on different hosts - my span-to-200-iterations on whey and jobreg-derive-cadence.py v2's expression-derived 21d target reaching 29.1d span. The row carries the semantic in its purpose column so it argues against its own reversion. None of that fixes the model: the correct instrument for a position-varying gap is the calendar's own next-elapse, not any fixed interval, and the row is only survivable because a human sentence is doing work the schema should do. Fleet exposure, for whoever implements: whey has exactly ONE across-days row, venus has ZERO range restrictions of any kind, lezama has two weekday-restricted rows already hand-computed as Fri-close -> Mon-open and both conservative. So the population this defect governs is small today and the cost of getting it wrong is a watchdog that either cries weekly or sleeps for 61 hours.