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

[Martin Pitt]

A convenient way to test this is to install libnss-resolve and cloud-
init into a yakkety container. Then cloud-init will basically hang
forever, looping on

  2016-10-04 12:58:48,716 - url_helper.py[WARNING]: Calling
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed
[100/120s]: request error [HTTPConnectionPool(host='169.254.169.254',
port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-
id (Caused by
NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection
object at 0x7f2495137b38>: Failed to establish a new connection: [Errno
113] No route to host',))]

and since cloud-init.service runs during early boot, not much else
(dbus, resolved, etc.) has started at that time. During that, name
resolution is indeed broken.

I think nss-resolve should quickly fall back to DNS if D-Bus isn't
running yet.

** Changed in: systemd (Ubuntu)
       Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd 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 package in Ubuntu:
  Invalid
Status in systemd 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/ubuntu/+source/cloud-init/+bug/1629797/+subscriptions