24h Update expiration w/ user confirmation

General Discussions
1

In the docs there’s the highlighted text “Maximum wait time between Sync and Download state is 24 hours, after this period the update will be marked as failed by the Mender client. This happens because the Mender Artifact download link is generated in Sync state and it has a expiration time (24 hours).” I’m curious on how to cheat my way around this timeout. I already tried to put user confirmation into the Download_Leave script, deployed and update, confirmed only after 26 hours and that went through fine. Now I’m speculating about what conclusions I may draw from this:

  • hypothesis 1) Since the download has already long finished in Download_Leave, the client might not care anymore that its download link is invalid - all data is locally present and the update can proceed.
  • hypothesis 2) The expiration time isn’t exactly 24 hours and I just slipped through the grace period

hypothesis 1 is a bit wishful thinking on my side. Where I could give an end user a popup message “update available” and have it present for days or weeks until the accept it (maybe even accept the update when the device has no internet connection anymore).

Can you confirm or deny that I can basically stay in Download_Leave as long as I want (or as long as StateScriptRetryTimeoutSeconds allows) without having my update fail? Also, how would the web interface react to such a situation? I assume a deployment can’t stay in active forever, would it go into fail on the webUI … and then a few days later when the end user comes online after the update I would just see the device with a new installed software version in the device management?

Thanks in advance,
Paul

2

I can confirm that you can stay in Download_Leave for as long as you want, as long as the timeouts don’t expire. There is one caveat though: If you restart, then Mender considers the update failed.

But for indefinite waits such as yours, and especially if it requires user input, I would consider using the device-side API instead. It is more tailored towards user interaction, and with this you can set your timeouts pretty low and still wait indefinitely, because it has a mechanism for refreshing the wait.

The Web UI doesn’t care how long it remains in progress, it just obeys what the device says.