[Bug 2034656] Re: Update Ubuntu ESM cache only once daily?

[Julian Andres Klode]

Yes so esm archive is contacted whenever main archive is, as the service
is started by a hook to apt update to run an apt update on a subcache.

And APT daily only runs once on a given calendar day, even if you
configure lower intervals.

So this seems to me like misconfiguration of those systems and not a pro
issue. Adding checks to pro would be dangerous, it's easy to get this
wrong in the current architecture, it may then only run every 2 days if
done the wrong way (you can't just check if you last checked 24 hours
ago, because if the daily run runs 22 hours due to randomisation you
wouldn't run, hence why apt normalizes the time stamps to midnight so it
sees if the date is different).

And really we want you to get the up-to-date information for your ESM
too if you run apt update (also when ESM is actually enrolled, it runs
in the main update anyhow).

Azure has its own update management solution afaik, which will do its
own update checks and update management, it's possible it checks
multiple times per day and should be relying on the randomised once a
day apt-daily instead.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/2034656

Title:
  Update Ubuntu ESM cache only once daily?

Status in cloud-images:
  New
Status in apt package in Ubuntu:
  New
Status in ubuntu-advantage-tools package in Ubuntu:
  Incomplete

Bug description:
  Hi,

  We're seeing frequent alerts on the Ubuntu ESM archive servers due to
  surges in requests. On two systems, I'm seeing this:

  | Sep  6 05:47:16 machine-2 systemd[1]: Starting Update the local ESM caches...
  | Sep  6 05:47:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 10:49:35 machine-2 systemd[1]: Starting Update the local ESM caches...
  | Sep  6 10:49:35 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 17:17:16 machine-2 systemd[1]: Starting Update the local ESM caches...
  | Sep  6 17:17:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 23:47:16 machine-2 systemd[1]: Starting Update the local ESM caches...
  | Sep  6 23:47:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  7 01:55:02 machine-2 systemd[1]: Starting Update the local ESM caches...
  | Sep  7 01:55:02 machine-2 systemd[1]: Finished Update the local ESM caches.

  On another:

  | Sep  6 02:41:02 is-bastion-ps5 systemd[1]: Starting Update the local ESM caches...
  | Sep  6 02:41:03 is-bastion-ps5 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 09:02:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM caches...
  | Sep  6 09:02:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 15:32:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM caches...
  | Sep  6 15:32:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 22:02:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM caches...
  | Sep  6 22:02:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM caches.
  | Sep  7 04:32:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM caches...
  | Sep  7 04:32:42 is-bastion-ps5 systemd[1]: Finished Update the local ESM caches.

  This is all from `/usr/lib/systemd/system/esm-cache.service` which
  calls `/usr/lib/ubuntu-advantage/esm_cache.py`.

  Can we please have this run less frequent? Perhaps only once daily
  which aligns with APT and apt-daily-upgrade.service / unattended-
  upgrades?

  Perhaps check existence of a file and run if not, then age of that
  same file and only run if it's older than a day?

  I think, from what I can see, this may be triggered from
  /lib/systemd/system/ua-timer.timer and /etc/apt/apt.conf.d/20apt-esm-
  hook.conf?

  See also LP:1554848 which was for APT.

  On Trusty and Xenial clients we only seem to update daily, but the
  problem is worse as it's a cron.daily job, so all clients fire
  simultaneously - could we get this changed to a cron.d job with a
  randomised firing time instead?

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2034656/+subscriptions