I’m trying to improve the refresh-behavior of our IoT devices, specifically related to snaps that require a system reboot (core, pi-kernel). We manage refreshes ourselves (refresh hold and manual refresh commands via snapd REST API).
So far, we checked which snaps have updates available and refreshed each individually, in order to have more control and add custom behavior (e.g. restart snaps with refresh-mode: endure).
I see two downsides with this:
Slower system refreshes due to sequential updates
Potentially multiple reboots if both core and pi-kernels have updates available
What would be the best way to achieve this?
From what I can see, we could either do a “global refresh” (POST /snaps {action: refresh}) or first check which snaps have updates available and then refresh them together (POST /snaps {action: refresh, snaps: [...]}). Both of these seem to perform the updates sequentially but just do a single reboot.
To do updates in parallel, we could do the non-reboot-refreshes in parallel and then core/pi-kernel in a single request, with a single reboot at the end of the updates. Is there a particular reason not to do this, or maybe some better way?
Additionally, I’m wondering about system-restart-immediate (system-restart-immediate: if true, makes any system restart, needed by the action, immediate and without delay (requires snapd 2.52) - I didn’t find more details and I understand what it does, but I’m unsure how this is meant to be used - what are advantages/disadvantages of rebooting immediately (or not)? How does this interact with a “global refresh”, e.g. does system-restart-immediate=false hold off on the reboot until all snaps are actually refreshed, while system-restart-immediate=true would reboot as soon as a core/pi-kernel snap is refreshed (and continue refreshing the other snaps after the reboot)?
To do updates in parallel, we could do the non-reboot-refreshes in parallel and then core/pi-kernel in a single request, with a single reboot at the end of the updates. Is there a particular reason not to do this, or maybe some better way?
The way you describe is close to what would happen by just doing a global refresh. Currently on an Ubuntu Core system snaps are updated in the following order:
Snapd snap
Essential snaps (boot base, gadget, kernel), no matter the combination of these 3, only one reboot should be scheduled at this stage, and the change will be blocked until this restart takes place.
After reboot, non-boot bases will update in parallel if possible
After non-boot bases, apps will update in parallel if possible
For the quickest update possible, I’d schedule all snaps that need to be refreshed into one change and just execute that. You can schedule the non-essential snaps first, and then the essential ones as well for something similar, but you’d have to do that manually.
Additionally, I’m wondering about system-restart-immediate (system-restart-immediate: if true, makes any system restart, needed by the action, immediate and without delay (requires snapd 2.52) - I didn’t find more details and I understand what it does, but I’m unsure how this is meant to be used - what are advantages/disadvantages of rebooting immediately (or not)? How does this interact with a “global refresh”, e.g. does system-restart-immediate=false hold off on the reboot until all snaps are actually refreshed, while system-restart-immediate=true would reboot as soon as a core/pi-kernel snap is refreshed (and continue refreshing the other snaps after the reboot)?
When a restart is scheduled by snapd (e.g pi-kernel requests a restart to continue update), that update will be scheduled to be executed in 1 minute from the request occurs. If system-restart-immediate is set to true, this will occur immediately instead of waiting 1 minute.
The advantages is that the system does not wait this 1 minute, if your other system/app services does not need this time, then you can let it reboot immediately. Snapd will gracefully shutdown in either case, and any change in progress will still run to a natural pause, and then resume after reboot.
