systemd-networkd runs too late for cloud-init.service (net)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
systemd |
Fix Released
|
Unknown
|
|||
systemd (Ubuntu) |
Fix Released
|
Medium
|
Martin Pitt | ||
Xenial |
Fix Released
|
High
|
Unassigned | ||
Yakkety |
Fix Released
|
Medium
|
Unassigned |
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)
DefaultDependen
Wants=cloud-
Wants=local-
Wants=sshd-
Wants=sshd.service
After=cloud-
After=networkin
Requires=
Before=basic.target
Before=dbus.socket
Before=
Before=
Before=sshd.service
Before=
Conflicts=
Here's networkd unit deps:
[Unit]
Description=Network Service
Documentation=
ConditionCapabi
DefaultDependen
# dbus.service can be dropped once on kdbus, and systemd-
# dropped once tuntap is moved to netlink
After=systemd-
Before=
Conflicts=
Wants=network.
# On kdbus systems we pull in the busname explicitly, because it
# carries policy that allows the daemon to acquire its name.
Wants=org.
After=org.
And a critical-chain output:
root@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@snap-test7:~# systemd-analyze critical-chain systemd-
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-
└─dbus.service @11.461s
└─basic.target @11.403s
└─sockets.
└─dbus.socket @11.398s
cloud-init would need networkd to run at or before 'networking.
# grep systemd /usr/share/
ii libnss-
ii libpam-
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/
ii cloud-init 0.7.8-201610260
SRU INFORMATION FOR systemd
=======
Fix: For xenial it is sufficient to drop systemd-networkd's After=dbus.service (https:/
Regression potential: Low. networkd is not widely being used outside of netplan/snappy in xenial. Running it before dbus.service is running has two consequences:
- It cannot immediately expose its D-Bus status interface. But it will retry every 5 s until that succeeds, so the D-Bus status interface will continue to work. (see test case)
- If a DHCP response with a hostname or timezone is received before dbus.service is running, it cannot talk to systemd-
As for removing the "*.busname" units in xenial: kdbus has never been part of any distribiution, there had just been some experimental DKMS package in some PPA for it. It's dead as an upstream project, so by dropping the *.busname unit(s) from xenial there should be no practical effect as these should always not start with "condition failed". Yakkety's systemd already has them removed.
Test case:
- Install nplan, set up a netplan configuration and remove /etc/network/
- Upgrade to the proposed packages.
- Ensure that the network is still functional and "busctl" shows org.freedesktop
- Check the journal that systemd-
If it repeatedly starts the other way around, you can force it with "sudo systemctl edit systemd-
[Unit]
Before=
(This is effectively what cloud-init.service will do soon.)
Related branches
- Martin Pitt (community): Approve
- cloud-init Commiters: Pending requested
-
Diff: 44 lines (+4/-6)2 files modifiedsystemd/cloud-init-local.service (+2/-2)
systemd/cloud-init.service (+2/-4)
Changed in systemd (Ubuntu): | |
importance: | Undecided → High |
assignee: | nobody → Martin Pitt (pitti) |
Changed in cloud-init (Ubuntu): | |
assignee: | nobody → Martin Pitt (pitti) |
importance: | Undecided → High |
Changed in systemd: | |
status: | Unknown → New |
Changed in systemd (Ubuntu Xenial): | |
status: | In Progress → Triaged |
Changed in cloud-init (Ubuntu Xenial): | |
status: | New → Confirmed |
importance: | Undecided → Medium |
Changed in cloud-init (Ubuntu): | |
status: | Fix Released → Triaged |
Changed in systemd (Ubuntu): | |
status: | Triaged → In Progress |
description: | updated |
description: | updated |
description: | updated |
Changed in systemd: | |
status: | New → Fix Released |
Changed in systemd (Ubuntu Xenial): | |
assignee: | Martin Pitt (pitti) → nobody |
Changed in resolvconf (Ubuntu Xenial): | |
status: | Triaged → In Progress |
Changed in resolvconf (Ubuntu Yakkety): | |
status: | Triaged → In Progress |
Changed in resolvconf (Debian): | |
status: | Unknown → New |
tags: |
added: verification-done removed: verification-needed |
Changed in resolvconf (Debian): | |
status: | New → Fix Committed |
Changed in systemd (Ubuntu Yakkety): | |
importance: | Undecided → Medium |
no longer affects: | resolvconf (Ubuntu Yakkety) |
no longer affects: | resolvconf (Ubuntu Xenial) |
no longer affects: | resolvconf (Ubuntu) |
affects: | resolvconf (Debian) → ubuntu-translations |
Changed in ubuntu-translations: | |
importance: | Unknown → Undecided |
status: | Fix Committed → New |
no longer affects: | ubuntu-translations |
Changed in cloud-init (Ubuntu Yakkety): | |
importance: | Undecided → Medium |
tags: | removed: verification-needed |
no longer affects: | cloud-init |
no longer affects: | cloud-init (Ubuntu) |
no longer affects: | cloud-init (Ubuntu Xenial) |
no longer affects: | cloud-init (Ubuntu Yakkety) |
cloud-init already has *very* strong dependencies:
Requires= networking. service basic.target
Before=
(which is sorting the early boot fairly strictly). But I guess in the same vein, if cloud-init wants to run in between networkd and basic.target, it needs to grow an After=systemd- networkd. service. I also suggest to replace the "Requires= networking. service" with "After= networking. service" as ifupdown is not mandatory any more.
However, due to networkd's After=dbus.service this wouldn't work yet, as dbus.service runs in late boot -- I proposed/tried to change this, but it's not ready for that (bug 1629797, https:/ /bugs.freedeskt op.org/ show_bug. cgi?id= 98254).
networkd can run without D-Bus in principle, but if that is not running yet but dbus.socket is we'll run into deadlocks again -- and if we start it before we need to teach it to connect to D-Bus once it becomes available.