Auto-upgrade snapd daily at 11:00 (opposite snapd's refresh window)#755
Open
cyberb wants to merge 1 commit into
Open
Auto-upgrade snapd daily at 11:00 (opposite snapd's refresh window)#755cyberb wants to merge 1 commit into
cyberb wants to merge 1 commit into
Conversation
snapd on Syncloud is an out-of-band host binary (installed from a tarball
into /usr/lib/snapd), not a snap, so snapd's own auto-refresh timer never
upgrades the snapd daemon itself. Until now the only way to pick up a new
snapd was the manual POST /rest/installer/upgrade button, while the platform
base snap and app snaps auto-refresh nightly (defaultRefreshScheduleStr
"23:00~24:00/1" in the snapd fork).
Close that gap with a cron job that, once a day at 11:00, compares the store
snapd version (apps.syncloud.org/releases/<channel>/snapd2.version) against
the installed version and, if they differ, runs the existing tarball upgrade
via JobMaster ("installer.upgrade") — the same serialized path the manual
button uses, so it can't race an app install or a manual upgrade.
11:00 is chosen as the opposite of the 23:00-24:00 refresh window so the
snapd swap never overlaps snapd applying a platform/app refresh, and a bad
upgrade surfaces during the day rather than overnight.
Registering the installer.Installer singleton before the new job because
golobby resolves singletons eagerly at registration time.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds a cron
SnapdUpgradeJobthat automatically upgrades the snapd daemon once a day at 11:00, deliberately opposite snapd's own nightly refresh window (23:00~24:00/1).Why
On Syncloud, snapd is an out-of-band host binary (extracted from a tarball into
/usr/lib/snapd), not a snap. So snapd's auto-refresh timer refreshes theplatformbase snap and app snaps nightly, but never upgrades the snapd daemon itself — that only happened via the manualPOST /rest/installer/upgradebutton.This closes that gap while avoiding the genuinely risky alternative of packaging snapd as a self-refreshing snap (a daemon replacing its own running binary during the refresh window).
How
Every 5-min cron tick, the job checks
SimpleScheduler.ShouldRun(day=0, hour=11, …). When it fires it compares:apps.syncloud.org/releases/<channel>/snapd2.version/v2/system-infoand if they differ, runs the existing tarball upgrade through
JobMaster.Offer("installer.upgrade", …)— the same serialized path the manual button uses, so it can't race an app install or manual upgrade. On a busy JobMaster it retries within the hour; otherwise it runs at most once per day.11:00 keeps the snapd stop/swap/restart clear of the 23:00–24:00 window (so it never overlaps snapd applying a platform/app refresh) and surfaces a bad upgrade during the day rather than overnight.
Notes / follow-ups
installer.Installersingleton before the new job (golobby resolves singletons eagerly).upgrade.shcurrentlycps over the live binary with no rollback or post-restart health check. Now that it runs unattended, adding backup + rollback + asnap --version/system-info health check would make a failed auto-upgrade self-recovering.Test
go test ./cron/... ./ioc/... ./job/...pass. Pre-existingidentification/networktest failures are environmental (Termux sandbox netlink/proc), unrelated to this change.