** Also affects: dbus (Ubuntu Yakkety)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Yakkety)
Importance: Undecided
Status: New
** Also affects: dbus (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: cloud-init (Ubuntu Xenial)
Status: New => Confirmed
** Changed in: cloud-init (Ubuntu Yakkety)
Status: New => Confirmed
** Changed in: cloud-init (Ubuntu Xenial)
Importance: Undecided => Medium
** Changed in: cloud-init (Ubuntu Yakkety)
Importance: Undecided => Medium
** Changed in: cloud-init (Ubuntu Yakkety)
Status: Confirmed => Fix Released
** Changed in: dbus (Ubuntu Xenial)
Status: New => Invalid
** Changed in: dbus (Ubuntu Yakkety)
Status: New => Invalid
** No longer affects: dbus (Ubuntu Xenial)
** No longer affects: dbus (Ubuntu Yakkety)
** Description changed:
- 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.
+ === Begin SRU Template ===
+ [Impact]
+ In cases where cloud-init used dns during early boot and system was
+ configured in nsswitch.conf to use systemd-resolvd, the system would
+ timeout on dns attempts making system boot terribly slow.
+
+ [Test Case]
+ Boot a system on GCE.
+ check for WARN in /var/log/messages
+ check that time to boot is reasonable (<30 seconds). In failure case the
+ times would be minutes.
+
+ [Regression Potential]
+ Changing order in boot can be dangerous. There is real chance for
+ regression here, but it should be fairly small as xenial does not include
+ systemd-resolved usage. This was first noticed on yakkety where it did.
+
+ [Other Info]
+ It seems useful to SRU this in the event that systemd-resolvd is used
+ on 16.04 or the case where user upgrades components (admittedly small use
+ case).
+
+ === End SRU Template ===
+
+
+
+ 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 नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 D-Bus:
Unknown
Status in cloud-init package in Ubuntu:
Fix Released
Status in dbus package in Ubuntu:
Won't Fix
Status in cloud-init source package in Xenial:
Confirmed
Status in cloud-init source package in Yakkety:
Fix Released
Bug description:
=== Begin SRU Template ===
[Impact]
In cases where cloud-init used dns during early boot and system was
configured in nsswitch.conf to use systemd-resolvd, the system would
timeout on dns attempts making system boot terribly slow.
[Test Case]
Boot a system on GCE.
check for WARN in /var/log/messages
check that time to boot is reasonable (<30 seconds). In failure case the
times would be minutes.
[Regression Potential]
Changing order in boot can be dangerous. There is real chance for
regression here, but it should be fairly small as xenial does not include
systemd-resolved usage. This was first noticed on yakkety where it did.
[Other Info]
It seems useful to SRU this in the event that systemd-resolvd is used
on 16.04 or the case where user upgrades components (admittedly small use
case).
=== End SRU Template ===
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
_______________________________________________
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
