From 9411628779f1b02dc6bef62a7d68b3e2d71ca80c Mon Sep 17 00:00:00 2001 From: Michael Vogt Date: Mon, 9 Nov 2026 08:45:40 +0100 Subject: [PATCH] contrib: increase quarry update timer to 8h With the deployment of the "kickd" varlink based backchannel to trigger updates by the ACP we no longer need the extremly aggressive 2min update timer. Instead this commit moves to a more reasonable 8h with a 30min spread. As side effect of the spread is that on boot the first update is also only checked after the spread. That is okay for now but we should have a mode that checks for updates first thing (even before servics come up) eventually. ENG-100 --- contrib/systemd/quarry-sysupdate.timer | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-) diff --git a/contrib/systemd/quarry-sysupdate.timer b/contrib/systemd/quarry-sysupdate.timer index 47e89a2..6823784 100644 --- a/contrib/systemd/quarry-sysupdate.timer +++ b/contrib/systemd/quarry-sysupdate.timer @@ -11,21 +11,10 @@ Description=Quarry-Based Automatic System Update ConditionVirtualization=!container [Timer] -Persistent=yes -# To make update provisioning more responsive, trigger updates on a minimum -# 2-minute interval (and 1 minute after boot). For large update payloads (like -# installing k8s) the update might take a while so we add a minimum 2 minute -# trigger from the unit start and end to make sure we never wait more than 2 -# minutes. -# -# FIXME: This is a workaround for ACP not being able to trigger updates via -# the "kickd" backchannel at the moment, in future this should probably be -# bumped higher? Or maybe we should still do this if the machine has no -# backchannel with the ACP? For obvious reasons this will probably not scale. OnBootSec=1min -OnUnitActiveSec=2min -OnUnitInactiveSec=2min -RandomizedDelaySec=20sec +OnUnitActiveSec=8h +# RandomizedDelay is applied to both options above +RandomizedDelaySec=30min [Install] WantedBy=timers.target