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