After further investigation, I’ve confirmed that the D-Bus API for synchronized updates is deprecated as of Mender 3.6.
While the documentation was somewhat unclear, the Mender 3.6 release notes are explicit. They state that the synchronized updates feature is being used when “Setting the control map on the device using the DBus API.”
Several other findings support this conclusion:
- Running the
gdbus
call to set the update control map returns(0,)
, which is an unexpected result for arefresh_timeout
.sudo gdbus call --system --dest io.mender.UpdateManager --object-path /io/mender/UpdateManager --method io.mender.Update1.SetUpdateControlMap '{"priority": 1, "states": {"ArtifactInstall_Enter": {"action": "pause"}}, "id": "01234567-89ab-cdef-0123-456789abcdef"}'
- The official mender-client-python-example repository on GitHub is archived and produces an error when run.
- The forum post I was referencing was created before the Mender 3.6 release, when the feature was still active.
With the D-Bus option unavailable, the only viable solution seems to be to increase StateScriptTimeoutSeconds
in /etc/mender/mender.conf
to something like 12 hours and use the state script outlined in my initial post.
On a related note, I feel that a limitation of the Mender client is the lack of a simple interface for observing its current status on the device side. While state scripts are effective for reacting to state changes and they can export these changes to other applications on the system, they do not seem to provide a mechanism for tracking other useful metrics, such as real-time download progress. Maybe a unix socket that outputs state information would already be enough. Something to think about!