pro-client doesn't run apt upgrade in any scenario or configure the
system to do so.

Do we have control over any of the offending machines? I'd still like to
see a `pro collect-logs` from one of them to be sure nothing unexpected
is happening pro-client related.

That the major offending package is azure-specific may be a clue that it
could be something happening only on Azure. We can talk to the cloud
team about it. We would only see the spike on esm.ubuntu.com because
clouds use mirrors for the main archive. Adding cloud-images here which
I think will notify them.

I went ahead and checked default apt configuration on a couple machines and 
found the following:
on Azure Bionic Pro:
$ apt-config dump | grep Periodic
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "0";
APT::Periodic::Unattended-Upgrade "1";

on GCP Bionic Pro:
$ apt-config dump | grep Periodic
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "1";
APT::Periodic::Unattended-Upgrade "1";

So at least in those two places, "Download-Upgradeable-Packages" is
disabled ("0"), which I believe is what corresponds to the apt upgrade
--download-only in apt.daily, but I'm out of my depth here. Just to be
sure though, I'm also adding this bug to apt in case this is a problem
with default configuration there.




** Also affects: apt (Ubuntu)
   Importance: Undecided
       Status: New

** Also affects: cloud-images
   Importance: Undecided
       Status: New

** Changed in: ubuntu-advantage-tools (Ubuntu)
       Status: Confirmed => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to