I’m implementing the UI side to allow our users to control Updates, using the Aktualizr d-bus api.
I’m experimenting with our container-based UI application for now.
After accepting an update through Consent Aktualizr starts downloading and extracting as seen through journalctl -f -u "aktualizr*".
If Cancel is called, sometimes is works, and I see
Jul 17 06:20:32 colibri-imx8x-06899690 aktualizr-torizon[10169]: 491d0bc84337 Extracting [======> ] 14.48MB/109.7MB
Jul 17 06:20:32 colibri-imx8x-06899690 aktualizr-torizon[10169]: 4cc171a464f2 Extracting [====================> ] 37.88MB/90.24MB
Jul 17 06:20:32 colibri-imx8x-06899690 aktualizr-torizon[1044]: Killing child process due to flow_control abort
Jul 17 06:20:32 colibri-imx8x-06899690 aktualizr-torizon[10169]: canceled
Jul 17 06:20:50 colibri-imx8x-06899690 aktualizr-torizon[1044]: Event: AllInstallsComplete, Result - OPERATION_CANCELLED
Jul 17 06:21:00 colibri-imx8x-06899690 aktualizr-torizon[10727]: ACTION HANDLER: get-firmware-info
Jul 17 06:21:02 colibri-imx8x-06899690 aktualizr-torizon[1044]: Consent was granted over D-Bus when no request pending. Ignoring
Jul 17 06:21:14 colibri-imx8x-06899690 aktualizr-torizon[1044]: Event: PutManifestComplete, Result - Success
Jul 17 06:26:00 colibri-imx8x-06899690 aktualizr-torizon[1044]: CheckForUpdates woke Aktualizr thread
However, sometimes it doesn’t. I see no “canceled”[sic] in the journal, and the operation completes, causing the existing application to be removed and the downloaded version is started (which would be a disaster for our users).
Is there something I can do to get this working ?
Is it that the last (long) stage in the update - downloading and starting the application container - has already started ?
Another thought was that I’ve noticed that our UI freezes for periods of some seconds when an update is downloading. Could that be preventing the Cancel message getting through ?! Seems a little unlikely (the download takes several minutes).
Ideally, of course, we would like to be able to control
the download - if it it happens or not, and with low or high priority (which may or may not be controlled by the user)
final activation (almost certainly controlled by the user)
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
To help you troubleshoot the D-Bus Cancel API issue, could you first confirm:
Which version of Torizon OS are you running? (You can check with tdx-info - see tdx-info documentation)
Which Toradex hardware module are you using? (e.g., Colibri iMX8X)
This information is important because the D-Bus API for granular control of Aktualizr is available in Torizon OS 7.4.0 or newer(1), and behavior may vary between versions.
What the Documentation Says
The D-Bus interface includes a Cancel method that should allow canceling an ongoing update and return Aktualizr to its idle state(1). However, the documentation notes this is an early access feature where “breaking changes can be introduced at any time”(1).
Possible Explanations for Inconsistent Cancel Behavior
Based on the logs you’ve shared, there appear to be race conditions where:
Cancel works: You see “canceled” and “OPERATION_CANCELLED” in the logs
Cancel fails: The update completes despite the Cancel call
This could happen if:
The update has progressed past a cancellation checkpoint
There’s a timing issue between when Cancel is called and when Aktualizr processes it
The container download/extraction phase has transitioned to the final activation stage
Regarding your UI freezing: while unlikely to block D-Bus messages entirely, if your UI application shares system resources heavily during the download, it could delay message processing.
Recommendations
Monitor the D-Bus properties to track update state before calling Cancel
Check the exact Aktualizr state when Cancel is invoked - there may be specific states where cancellation is no longer possible
Consider the update workflow: You mentioned wanting to control download vs. activation separately - the Consent API in Torizon OS 7.4.0+ allows configuring Aktualizr to wait for consent before proceeding(1)
Could you share your Torizon OS version so I can provide more specific guidance?
**
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Just to be clear, the (failed) Cancel is issued while the download/extraction is ongoing.
For Cancel to be useful, we would need a signal to indicate when Cancel will be ignored. And this should be the point just before the container swap (or OS reboot - though maybe we will just prevent the OS reboot).
Thank you for the clarification. Your point about needing a signal to indicate when Cancel will be ignored is very valid and highlights a gap in the current D-Bus API implementation.
Current Limitations
As you’ve discovered, the Granular Control via D-Bus is an early access feature(1), and the documentation explicitly warns that “breaking changes can be introduced at any time”(1). The inconsistent Cancel behavior you’re experiencing—where it sometimes works during download/extraction and sometimes doesn’t—suggests there’s no clear boundary or signal indicating when cancellation is no longer possible.
What You’re Asking For
Your requirement is reasonable:
A clear signal/property indicating whether Cancel will be honored
This boundary should be just before the container swap (or OS reboot)
This would allow your UI to disable the Cancel button at the appropriate time
Unfortunately, based on the available documentation, there doesn’t appear to be such a signal or property exposed through the D-Bus API currently(1).
Alternative Approach: Consent API
Since you mentioned wanting to control download vs. activation separately, the Consent API might be more suitable for your use case:
Configure Aktualizr to wait for consent before proceeding with the update(1)
This gives you explicit control over when the update activates
Users can review the update details before final approval
However, this doesn’t solve the download cancellation issue you’re experiencing.
Recommended Next Steps
Disable the Cancel feature for your users (as you’re planning) until this is more stable
Share your feedback with Toradex about needing a clear cancellation boundary signal—the documentation encourages users to “share feedback on how effectively the feature supports their use cases”(1)
Consider using the Consent API to control final activation separately from download
Could you confirm your Torizon OS version? This will help determine if there are any version-specific behaviors or if updates have addressed this issue.
Best regards,
Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Jul 17 06:49:19 colibri-imx8x-06899690 aktualizr-torizon[1044]: Event: DownloadProgressReport, Progress at 100%
Jul 17 06:49:19 colibri-imx8x-06899690 aktualizr-torizon[1044]: Event: DownloadTargetComplete, Result - Success
Jul 17 06:49:19 colibri-imx8x-06899690 aktualizr-torizon[1044]: Event: AllDownloadsComplete, Result - Success
They’re obviously good feedback for the UI, but could be used to indicate if Cancel is acceptable or not (though there could be some timing concern) unless more downloads occur after invoking the docker container ?
