Comment 3 for bug 2034656

Thank you for reporting this and sorry for the delay - for some reason this bug hasn't shown up in the team's daily summary email :( (I'll look into why)

There are a couple cases to consider here:
1. Xenial onward all have v28.1 in -updates
2. Trusty is back on v19.6 in -updates
3. Cloud Pro Trusty instances I think got v26.3 but I don't seem to be able to launch a new one to verify

Xenial onward with v28.1 have the esm-cache.service but it is only supposed to run when `apt update` runs. Is there something on these systems that is triggering an apt update every few hours? On these instances, a `pro collect-logs` will generate a tarball of logs named ua_logs.tar.gz - the contents of that may be helpful in figuring out what is causing this.

On Trusty v19.6 as well as 26.3 there is no esm-cache.service and esm sources are configured as normal apt sources (but pinned to 'never'), these should also only get updated on an `apt update`.

So I'm pretty sure that in all cases the esm cache is only updated when `apt update` runs. My initial thought is that any staggering or randomization should be implemented at the level that calls apt update, not at the level of the apt hook.

Or if esm is updating more frequently than on `apt update`, then that is likely a bug in pro-client and the logs from `pro collect-logs` would be helpful there.