[Bug 1636912] Re: systemd-networkd runs too late for cloud-init.service (net)
Ryan Harper
1636912 at bugs.launchpad.net
Thu Oct 27 03:04:10 UTC 2016
On Wed, Oct 26, 2016 at 6:41 PM, Steve Langasek <
steve.langasek at canonical.com> wrote:
> Note that the systemd dependencies shown for cloud-init in xenial (on
> which Ubuntu Core 16 is based) don't match those listed in the bug
> description. Instead, xenial currently has:
>
> After=cloud-init-local.service networking.service
> Before=network-online.target sshd.service sshd-keygen.service
> systemd-user-sessions.service
> Requires=networking.service
> Wants=local-fs.target cloud-init-local.service sshd.service
> sshd-keygen.service
>
> That's certainly an easier target for fixing the ordering on.
>
We're preparing an SRU for Xenial, but the issue is related to
systemd-resolved which is NOT in Xenial, so the
failing behavior of a 120 second timeout for resolving hosts when dbus
isn't up yet doesn't materialize on Xenial, only yakkety.
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1629797
>
> I'm surprised that cloud-init is being ordered before dbus in 16.10+.
> This appears to have been done in response to bug #1629797. This change
> to ordering on account of nss-resolve does not give me the warm fuzzies.
> There's feedback in the end of that bug that cloud-init should *not* be
> using Before=basic.target / Before=dbus.socket, but instead use
> Before=sysinit.target. That seems like a change we should be making. But
> I also didn't understand that we would be using nss-resolve - I missed a
> nuance in <https://lists.ubuntu.com/archives/ubuntu-devel/2016-
> June/039406.html>, I thought that once resolved supported DNS, we would
> use that /instead of/ the NSS module. Is there really a benefit to using
> both?
>
systemd-resolved doesn't runs soon enough where cloud-init needs to resolve
metadata service end points, like in GCE.
I don't know enough to say if resolved and NSS are 100% swappable; but at a
min, resolved would need to be able to run as early as NSS runs to allow
cloud-init to resolve metadata service URLS very early in boot.
>
> Regardless, none of that seems to account for the specific problem
> reported here, on Ubuntu Core 16; because Ubuntu Core 16 does contain
> libnss-resolve, but does *not* contain the cloud-init with the
> DefaultDependencies=no.
>
We're specifically introducing a newer cloud-init which adds support for
snap create-user support which also includes the change in Unit
dependencies from upstream cloud-init.
Those changes to unit dependencies will also be SRU to Xenial.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1636912
>
> Title:
> systemd-networkd runs too late for cloud-init.service (net)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+
> bug/1636912/+subscriptions
>
--
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/1636912
Title:
systemd-networkd runs too late for cloud-init.service (net)
Status in cloud-init package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Triaged
Bug description:
Ubuntu Core 16 images using cloud-init fail to function when the
DataSource is over the network (Like OpenStack) as networking is not
yet available when cloud-init.service runs.
cloud-init service unit deps look like this:
[Unit]
Description=Initial cloud-init job (metadata service crawler)
DefaultDependencies=no
Wants=cloud-init-local.service
Wants=local-fs.target
Wants=sshd-keygen.service
Wants=sshd.service
After=cloud-init-local.service
After=networking.service
Requires=networking.service
Before=basic.target
Before=dbus.socket
Before=network-online.target
Before=sshd-keygen.service
Before=sshd.service
Before=systemd-user-sessions.service
Conflicts=shutdown.target
Here's networkd unit deps:
[Unit]
Description=Network Service
Documentation=man:systemd-networkd.service(8)
ConditionCapability=CAP_NET_ADMIN
DefaultDependencies=no
# dbus.service can be dropped once on kdbus, and systemd-udevd.service can be
# dropped once tuntap is moved to netlink
After=systemd-udevd.service dbus.service network-pre.target systemd-sysusers.service systemd-sysctl.service
Before=network.target multi-user.target shutdown.target
Conflicts=shutdown.target
Wants=network.target
# On kdbus systems we pull in the busname explicitly, because it
# carries policy that allows the daemon to acquire its name.
Wants=org.freedesktop.network1.busname
After=org.freedesktop.network1.busname
And a critical-chain output:
root at snap-test7:~# systemd-analyze critical-chain systemd-networkd
Failed to get ID: Unit name systemd-networkd is not valid.
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
root at snap-test7:~# systemd-analyze critical-chain systemd-networkd.service
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
systemd-networkd.service +440ms
└─dbus.service @11.461s
└─basic.target @11.403s
└─sockets.target @11.401s
└─dbus.socket @11.398s
└─cloud-init.service @10.127s +1.266s
└─networking.service @9.305s +799ms
└─network-pre.target @9.295s
└─cloud-init-local.service @3.822s +5.469s
└─local-fs.target @3.813s
└─run-cgmanager-fs.mount @12.687s
└─local-fs-pre.target @1.393s
└─systemd-tmpfiles-setup-dev.service @1.116s +195ms
└─kmod-static-nodes.service @887ms +193ms
└─system.slice @783ms
└─-.slice @721ms
cloud-init would need networkd to run at or before 'networking.service' so it can raise networking to then find and use network-based datasources.
# grep systemd /usr/share/snappy/dpkg.list
ii libnss-resolve:amd64 229-4ubuntu11 amd64 nss module to resolve names via systemd-resolved
ii libpam-systemd:amd64 229-4ubuntu11 amd64 system and service manager - PAM module
ii libsystemd0:amd64 229-4ubuntu11 amd64 systemd utility library
ii systemd 229-4ubuntu11 amd64 system and service manager
ii systemd-sysv 229-4ubuntu11 amd64 system and service manager - SysV links
# grep cloud-init /usr/share/snappy/dpkg.list
ii cloud-init 0.7.8-201610260005-gf7a5756-0ubuntu1~trunk~ubuntu16.04.1 all Init scripts for cloud instances
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1636912/+subscriptions
More information about the foundations-bugs
mailing list