Adding After=systemd-resolved.service to /lib/systemd/system/cloud-
init.service causes the following in journalctl:
Oct 03 12:05:04 yakkety-161003-0945 systemd[1]: basic.target: Found ordering
cycle on basic.target/start
Oct 03 12:05:04 yakkety-161003-0945 systemd[1]: basic.target: Found dependency
on cloud-init.service/start
Oct 03 12:05:04 yakkety-161003-0945 systemd[1]: basic.target: Found dependency
on systemd-resolved.service/start
Oct 03 12:05:04 yakkety-161003-0945 systemd[1]: basic.target: Found dependency
on basic.target/start
Oct 03 12:05:04 yakkety-161003-0945 systemd[1]: basic.target: Breaking ordering
cycle by deleting job cloud-init.service/start
Oct 03 12:05:04 yakkety-161003-0945 systemd[1]: cloud-init.service: Job
cloud-init.service/start deleted to break ordering cycle starting with
basic.target/start
** Description changed:
- Seems 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.
+ 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.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
New
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
--
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
