[Bug 1629797] Re: resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up

[Dan Watkins]

To determine if this has been fixed, boot an image that has the GCE data
source enabled (e.g. the image from cloud-images.ubuntu.com) but not on
GCE.  Examine the output of `journalctl` and look for the following
lines:

Oct 07 16:17:39 ubuntu cloud-init[1009]: [CLOUDINIT] __init__.py[DEBUG]: Seeing if we can get any data from <class 'cloudinit.sources.DataSourceGCE.DataSourceGCE'>
Oct 07 16:19:19 ubuntu cloud-init[1009]: [CLOUDINIT] DataSourceGCE.py[DEBUG]: http://metadata.google.internal/computeMetadata/v1/ is not resolvable


The timestamps on them should be no more than fractions of a second apart (the above example is on a _broken_ instance).

(Note that, (a) there may be lines in between these two, and (b) you
have to use `journalctl` because cloud-init.log doesn't have correct
timestamps.)

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

Title:
  resolve service in nsswitch.conf adds 25 seconds to failed lookups
  before systemd-resolved is up

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  In Progress
Status in dbus package in Ubuntu:
  Triaged

Bug description:
  During boot, cloud-init does DNS resolution checks to if particular
  metadata services are available (in order to determine which cloud it
  is running on).  These checks happen before systemd-resolved is up[0]
  and if they resolve unsuccessfully they take 25 seconds to complete.

  This has substantial impact on boot time in all contexts, because
  cloud-init attempts to resolve three known-invalid addresses ("does-
  not-exist.example.com.", "example.invalid." and a random string) to
  enable it to detect when it's running in an environment where a DNS
  server will always return some sort of redirect.  As such, we're
  talking a minimum impact of 75 seconds in all environments.  This
  increases when cloud-init is configured to check for multiple
  environments.

  This means that yakkety is consistently taking 2-3 minutes to boot on
  EC2 and GCE, compared to the ~30 seconds of the first boot and ~10
  seconds thereafter in xenial.

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