Hi,
We would like to block upgrades in the first 10 minutes of the devices booting up. Even more so, it is critical upgrade does not start until UI is fully loaded (we use kiosk so it takes time for chrome and backend server to load).
What would be the best way to implement this upgrade policy?
Hey @n42 ,
You might want to take a look at update locks. It might help you achieve what you’re looking for.
Cheers,
Nico.
The update lock page specifically says:
“On devices running supervisor 7.22.0 and higher, the lockfile is located at /tmp/balena/updates.lock . This lock is cleared automatically when the device reboots, so the user app must take it every time it starts up.”
This basically says we cannot use the lock file to prevent upgrades during the boot process - and that it will basically be a race between supervisor and how quickly our container boots and locks the upgrade.
Any way around this?
Hey @n42, we have some ongoing internal discussions around the behaviour of update locks so I’m going to add your comments as I think it’s a valid case we need to be aware of. Thanks for pointing it out!
The intent of the lockfile is to prevent application updates during critical sections of your code, and in general we don’t expect critical code to be running during boot. Are you attempting to use locks to avoid updating certain devices at all? Could this be managed at a fleet level to set default releases for the fleet, or pin devices to a release via the dashboard or the balena APi?
I think if we understand your use case, why you need to prevent updates after a reboot, we can better address this in the product.
Sorry, I just re-read your first message and I see you answered some of these questions already.
it is critical upgrade does not start until UI is fully loaded
I’ll add these notes to our internal discussion!
Since this is nearly the opposite of how upgrade locks were designed to work, we may need to look at another workaround for now.
You could try adding another container to your application that sleeps for 10min after start, and then uses the balena API to pin itself to the desired/latest release for the fleet.
This can all be done programatically and as long as a device is pinned to a release it will never update on it’s own.
Hi,
Thank you for taking my input into consideration.
You are correct - as far as I can see, the only way to avoid upgrade during startup of the device, prior to UI loading, is to pin to release and manage the upgrade on our end. Since we already use pin to release for other use cases, we were hoping to have an independent mechanism to avoid upgrade during boot process (within first ~10 minutes or so until UI fully loads).