I know that Torizon OS uses Aktualizr to implement an out-of-the-box OTA update experience.
The device polls the server for new updates every 5 minutes and if an update is available is applied.
I tried and it works.
I read that I can block the updates using flock command.
Now I need a couple of customizations:
the device polls the server (it’s fine)
when a new update is available I need to notify my application (inside docker container) so that I can show ad advice to the user
if (and only if) the user selects “yes” the updates are applied
Which is the suggested approach?
Playing with flock to keep the updates blocked is safe even after a reboot?
How can I notify my application that updates are available?
Is there a set of .toml files to do this?
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
To achieve the customizations you need for OTA updates in Torizon OS using Aktualizr, you can follow the suggested approach outlined in the context:
Polling: Continue using the existing polling mechanism that checks for updates every 5 minutes, as it is already functioning as intended.
Notification to Application: To notify your application running inside a Docker container when an update is available, you can implement a custom notification mechanism. This could involve:
Using a messaging system or a file-based notification that your application can monitor.
Implementing a listener within your application that checks for update availability signals from Aktualizr.
User Confirmation: Use the flock command to block updates until the user confirms. This command can effectively maintain the lock even after a reboot, ensuring that updates are not applied until you explicitly allow them. You will need to ensure that your application logic handles the user confirmation process correctly.
Regarding the .toml configuration files, there may be a set of these files that can be used to customize the behavior of Aktualizr, including settings for notifications and user confirmation requirements. You should refer to the specific documentation for Torizon OS and Aktualizr for the correct parameters to set.
By implementing this approach, you can ensure that your application is notified of available updates, and updates are only applied with user consent, while safely managing the update process using flock.
Please, also check if these links can help you solve your problem:
Right now the control and feedback of Aktualizr is a bit limited. If you want to do what you described right now then you’ll need to use the flock method to block the update. When the user via your application/ui selects “yes” then your application or some mechanism on your system will need to remove the lock to allow the update to continue.
Playing with flock to keep the updates blocked is safe even after a reboot?
Not sure if I fully understand this question. Are you asking if the lock created by flock is persistent across system reboots? Since flock works via a process or command holding the file in a locked state. These processes would be disrupted in a system power cycle.
I would think then in most cases the flock needs to be reinstated after the system starts up again.
How can I notify my application that updates are available?
Right now the only feedback from Aktualizr is via the logs it outputs that can be seen in journald. If there is an update available you would see a log like: New updates found*.
Is there a set of .toml files to do this?
If you’re asking if there’s any configurations to do what you just described, then no at the current time there is not.
Now, with everything said, like I said at the start the current feedback and control a user has over Aktualizr and it’s actions is very limited. That said, we are currently planning a new feature for Aktualizr that will allow for increased feedback and control. This would allow users to send “commands” to Aktualizr via a mechanism (i.e. dbus) and get feedback from the client. That said this feature is still very early in the development stage so there’s not too many concrete details to share yet.
I try to explain a little bit my doubt.
Is there a risk that after a new reboot (or power up), before I can call flock, aktualizr can see an available update and install it?
I imagine it depends on the order of services start at the boot.
So I need to implement a polling mechanism of journald in my application.
Yes, that was the question.
Great news!
I hope it will be available quickly.
If you need some beta testing, I’m available.
Is there a risk that after a new reboot (or power up), before I can call flock, aktualizr can see an available update and install it?
I imagine it depends on the order of services start at the boot.
I understand now. Yes you are correct it would depend in the timing/order of the boot services. To be completely sure you would need the flock to be executed before the aktualizr service starts. That is if you are concerned an update might be received by the device first thing on boot. Which is possible. No matter the polling rate you set for aktualizr, it will check for available updates when it starts up. Unless of course you manage to get the flock in place before this.
So I need to implement a polling mechanism of journald in my application.
Correct. This is what I’ve seen other customers do as well. Unfortunately, the original design of Aktualizr didn’t really intend to provide much feedback outside of the journald log output. But, again this is something we hope to change and improve on in the future.
I hope it will be available quickly.
If you need some beta testing, I’m available.
Like I said, it’s still quite early in the development process for this new feature. Though it is a priority for our team this quarter. That said it’s still too early for me to say for sure when we’ll have something.
I see that you mentioned this feature in other topics on this community (here and here).
What you described is basically what I need.
I add only a couple of things, in case you don’t have it in your mind: 2. 3. 4.
if aktualizr reports that an update is available, the user has three options:
Update now - this will start the update
Remind me later - aktualizr will report again this update available after some time (1 day?, customizable?)
Dismiss - aktualizr will report only if a different update is available
Both in cases 1 and 2 a manual command “search for update now” should be available.
@jeremias.tx I hope that this clarifies my usage scenario (real application).
Thank you for the feedback. I believe we’ve already considered these actions/use-cases but I’ll let the team responsible know in case they didn’t have this in their design already.
