EVO-86: install and arm the two venus-crontick@ user timers on host venus
Install and arm the two EVO-86 venus host ticks. Files are already on origin/main at 4c97173 under venus/scripts/systemd/: cron-tick.sh, crontick-failnotify.sh, venus-crontick@.service, venus-crontick-failnotify@.service, venus-crontick@.timer, and one cadence drop-in per instance under venus-crontick@venus-drain-watchdog.timer.d/ and venus-crontick@venus-applog-watchdog.timer.d/. Instances: venus-drain-watchdog (*:0/15) and venus-applog-watchdog (*:15). ~/.local/bin/.llmmsg-env already carries CRONTICK_VENUS_BASE_URL=https://cmfpost-evolutiva.pensanta.com; VENUS_CRON_SECRET must be present in the same overlay or the tick exits 78 by design rather than guessing. ASSIGNED TO THIS SEAT BECAUSE ~/.config/systemd/user is your lane, not mine - the units are written and proven, only installation is left. TWO THINGS THAT WILL BITE. (1) The drop-ins must land WITH the timers: systemd ACCUMULATES OnCalendar= across drop-ins, which is why each cadence.conf opens with an empty OnCalendar= to clear the template hourly default. A drop-in that fails to install leaves the instance ticking hourly - deliberately the SAFER failure, it under-ticks rather than over-ticks a route that alerts. (2) The template default is hourly on purpose; do not edit it to the narrower cadence. WHAT CLOSES THIS ROW: systemctl --user list-timers output showing BOTH units with a real NEXT and a real LAST, plus one journalctl excerpt per unit showing a 200. An enable confirmation does not close it - armed is not running, and this epic has no cron.job_run_details to fall back on once the DB leg goes. Do NOT unschedule anything in the database; that is the sibling row and it goes SECOND.
Activity
-
parent=#2636
-
INDEPENDENTLY RE-VERIFIED on the host before closing, not accepted from the handoff - nw-venus-cc report matches on every claim I could re-read. list-timers: venus-crontick@venus-drain-watchdog LAST 2026-10-05 02:15:26 UTC NEXT 02:30:04; venus-crontick@venus-applog-watchdog LAST 02:15:26 NEXT 03:15:29. Both have a real LAST, so these are fires and not an enable. CADENCE IS NON-ACCUMULATING, which was the specific trap: systemctl show -p TimersCalendar returns exactly ONE OnCalendar per unit - drain *-*-* *:00/15:00, applog *-*-* *:15:00. The empty OnCalendar= reset in each drop-in did its job; had it been omitted both units would have carried the template hourly value AS WELL and read as the narrower one. JOURNAL, two consecutive drain fires and one applog fire, each a Starting/200/Finished triple: drain 200 in 0.418s and 0.318s with coverage=fresh ageMs 300935 and 299969 against beatMs 300000; applog 200 in 0.302s coverage=fresh ageMs 7171524 beatMs 21600000. A oneshot Finished IS the 2xx here because cron-tick exits nonzero on any non-2xx. NO ARTIFACT DRIFT. All three installed units and both drop-ins diff clean against the pushed copies, and git diff origin/main on scripts/systemd/ is empty, so the file systemd actually executed is byte-identical to 4c97173. ONE PROPERTY WORTH HAVING ON THE ROW AND IT IS NOT A DEFECT YET: ExecStart points at the repo working tree (/home/rob/.../venus/scripts/systemd/cron-tick.sh), not an installed copy under ~/.config. That is what the unit I wrote declares and it is why the drift check above is possible at all, but it also means an UNCOMMITTED local edit to that path changes production behaviour on the next fire with no deploy step. Same class as the /home/rob/scripts-vs-sh.git confusion, inverted: here the tracked copy IS the live one. HOST LEG GREEN. The EVO-109 gate is satisfied; unblocking it.
-
Closed on re-verified evidence, not on the handoff: both timers armed with real LASTs, one OnCalendar each, 200s in the journal, installed units byte-identical to 4c97173.