[Bug 1982218] Re: wait-online does not correctly identify managed links
Nick Rosbrook
1982218 at bugs.launchpad.net
Mon Aug 21 18:12:38 UTC 2023
> That's not appropriate. The test case should tell anyone the steps required
> to reproduce this bug and verify the fix. Setting up the VM is thus not out
> of scope.
Added instructions for creating the VM.
** Description changed:
[Impact]
systemd-networkd-wait-online will exit prematurely when the --any flag
is passed, due to an incorrect patch in Ubuntu that is supposed to make
systemd-networkd-wait-online exit when *no* links are managed.
[Test Plan]
- This test uses a VM managed by libvirt. The specifics of how to create
- the VM and how to define networks for use in libvirt are outside the
- scope of this test plan. But, in this scenario we have the "default"
- network which provides DHCP to the VM, and the "no-dhcp" network which
- does not provide DHCP.
+ This test uses a VM managed by libvirt. In this scenario we have the
+ "default" network which provides DHCP to the VM, and the "no-dhcp"
+ network which does not provide DHCP.
- 1. In the VM, write a network config for all en* links to use DHCP:
+ To setup the VM (this assumes Jammy, but the same steps apply for Lunar
+ using appropriate names and install media):
+
+ 1. Define the default and no-dhcp networks:
+
+ $ cat > /tmp/net-default.xml << EOF
+ <network>
+ <name>default</name>
+ <uuid>04260896-2701-422d-84e0-8e0df1122db3</uuid>
+ <forward mode='nat'/>
+ <bridge name='virbr0' stp='on' delay='0'/>
+ <mac address='52:54:00:bd:9f:3a'/>
+ <ip address='192.168.122.1' netmask='255.255.255.0'>
+ <dhcp>
+ <range start='192.168.122.2' end='192.168.122.254'/>
+ </dhcp>
+ </ip>
+ </network>
+ $ virsh net-create --file /tmp/net-default.xml
+ $ cat > /tmp/net-default.xml << EOF
+ <network>
+ <name>no-dhcp</name>
+ <uuid>2c047740-caab-4c90-8421-70da6732a759
+ </uuid>
+ <forward mode='nat'/>
+ <bridge name='virbr1' stp='on' delay='0'/>
+ <mac address='52:54:00:ac:12:45'/>
+ <ip address='172.16.1.1' netmask='255.255.0.0'>
+ </ip>
+ </network>
+ $ virsh net-create --file /tmp/net-no-dhcp.xml
+ $ virsh net-start --network default
+ $ virst net-start --network no-dhcp
+
+ 2. Create the VM using virt-install:
+
+ virt-install \
+ --connect=qemu:///system \
+ --name=jammy \
+ --arch=x86_64 \
+ --cpu=host-passthrough \
+ --ram=4096 \
+ --vcpus=1 \
+ --disk=path=/var/lib/libvirt/images/jammy.qcow2,size=24,format=qcow2,sparse=true,bus=virtio \
+ --virt-type=kvm \
+ --accelerate \
+ --hvm \
+ --cdrom=/tmp/ubuntu-22.04.2-live-server-amd64.iso \
+ --os-type=linux \
+ --os-variant=generic \
+ --graphics=spice \
+ --input=tablet \
+ --network=network=default,model=virtio \
+ --video=qxl \
+ --noreboot
+
+ 3. Complete the installation steps. Reboot the VM.
+
+ Run the test:
+
+ 1. Detach the network interface so that the test starts with no
+ interfaces attached:
+
+ $ virsh detach-interface $VM network
+
+ 2. In the VM, write a network config for all en* links to use DHCP:
$ cat > /etc/systemd/network/10-dhcp.network << EOF
[Match]
Name=en*
[Network]
DHCP=yes
EOF
- 2. Reload network configuration:
+ 3. Restart systemd-networkd:
- $ networkctl reload
+ $ systemctl restart systemd-networkd
- 3. On the host, attach an interface to the VM on the no-dhcp network, so
+ 4. On the host, attach an interface to the VM on the no-dhcp network, so
that an IP is not assigned:
$ virsh attach-interface $VM network no-dhcp
- 4. Back in the VM, confirm that the device is in the
+ 5. Back in the VM, confirm that the device is in the
degraded/configuring state:
$ networkctl
- networkctl
- IDX LINK TYPE OPERATIONAL SETUP
- 1 lo loopback carrier unmanaged
- 8 ens3 ether degraded configuring
+ networkctl
+ IDX LINK TYPE OPERATIONAL SETUP
+ 1 lo loopback carrier unmanaged
+ 8 ens3 ether degraded configuring
2 links listed.
- 5. Run systemd-networkd-wait-online --any, and confirm that it does
+ 6. Run systemd-networkd-wait-online --any, and confirm that it does
timeout instead of returning while the device is is still not
configured:
$ /lib/systemd/systemd-networkd-wait-online --any --timeout=10
Timeout occurred while waiting for network connectivity.
- 6. Confirm that the device is STILL in the degraded/configuring state:
+ 7. Confirm that the device is STILL in the degraded/configuring state:
$ networkctl
- IDX LINK TYPE OPERATIONAL SETUP
- 1 lo loopback carrier unmanaged
- 8 ens3 ether degraded configuring
+ IDX LINK TYPE OPERATIONAL SETUP
+ 1 lo loopback carrier unmanaged
+ 8 ens3 ether degraded configuring
2 links listed.
8. Now, leave systemd-network-wait-online --any running while we attach
another interface:
$ /lib/systemd/systemd-networkd-wait-online --any --timeout=0
9. On the host, attach another interface to the VM on the default
network, so that DHCP assigns the interface an IP:
$ virsh attach-interface $VM network default
10. Back in the VM, the systemd-networkd-wait-online process should have
exited with success, and networkctl should show the new link as
configured, while the old one is still configuring:
$ /lib/systemd/systemd-networkd-wait-online --any --timeout=0
$ echo $?
0
- $ networkctl
- IDX LINK TYPE OPERATIONAL SETUP
- 1 lo loopback carrier unmanaged
- 8 ens3 ether degraded configuring
- 9 ens9 ether routable configured
+ $ networkctl
+ IDX LINK TYPE OPERATIONAL SETUP
+ 1 lo loopback carrier unmanaged
+ 8 ens3 ether degraded configuring
+ 9 ens9 ether routable configured
3 links listed.
[Where problems could occur]
This patch we want to remove is totally confined to systemd-networkd-
wait-online, so that's where we would see problems. From what I can
tell, the patch is no longer doing what it was intended to do. E.g.
running systemd-networkd-wait-online on a desktop install, where
systemd-networkd does not manage links, results in a timeout. It only
works with the --any flag, but the --any flag did not exist when the
patch was written. If a user was relying on --any to make systemd-
networkd-wait-online exit when no links are managed, they will see a
change in behavior as a result of this change. However, the resulting
behavior will be consistent with the manual page.
[Original Description]
Ubuntu's packaging of systemd-networkd-wait-online includes a patch
(UBUNTU-wait-online-exit-if-no-links-are-managed) intended to exit if
none of the present links are managed by systemd-networkd. However, the
patch fails to identify links in the "configuring" state, which implies
they are managed, but not yet fully online. This undermines the purpose
of systemd-networkd-wait-online with the --any option, since at the time
the systemd-networkd-wait-online service is started, managed links are
_likely_ in a configuring, but-not-yet-configured state.
Please see the attached patch. Thanks!
** Changed in: systemd (Ubuntu Lunar)
Status: Incomplete => In Progress
--
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/1982218
Title:
wait-online does not correctly identify managed links
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Jammy:
Triaged
Status in systemd source package in Lunar:
In Progress
Bug description:
[Impact]
systemd-networkd-wait-online will exit prematurely when the --any flag
is passed, due to an incorrect patch in Ubuntu that is supposed to
make systemd-networkd-wait-online exit when *no* links are managed.
[Test Plan]
This test uses a VM managed by libvirt. In this scenario we have the
"default" network which provides DHCP to the VM, and the "no-dhcp"
network which does not provide DHCP.
To setup the VM (this assumes Jammy, but the same steps apply for
Lunar using appropriate names and install media):
1. Define the default and no-dhcp networks:
$ cat > /tmp/net-default.xml << EOF
<network>
<name>default</name>
<uuid>04260896-2701-422d-84e0-8e0df1122db3</uuid>
<forward mode='nat'/>
<bridge name='virbr0' stp='on' delay='0'/>
<mac address='52:54:00:bd:9f:3a'/>
<ip address='192.168.122.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.122.2' end='192.168.122.254'/>
</dhcp>
</ip>
</network>
$ virsh net-create --file /tmp/net-default.xml
$ cat > /tmp/net-default.xml << EOF
<network>
<name>no-dhcp</name>
<uuid>2c047740-caab-4c90-8421-70da6732a759
</uuid>
<forward mode='nat'/>
<bridge name='virbr1' stp='on' delay='0'/>
<mac address='52:54:00:ac:12:45'/>
<ip address='172.16.1.1' netmask='255.255.0.0'>
</ip>
</network>
$ virsh net-create --file /tmp/net-no-dhcp.xml
$ virsh net-start --network default
$ virst net-start --network no-dhcp
2. Create the VM using virt-install:
virt-install \
--connect=qemu:///system \
--name=jammy \
--arch=x86_64 \
--cpu=host-passthrough \
--ram=4096 \
--vcpus=1 \
--disk=path=/var/lib/libvirt/images/jammy.qcow2,size=24,format=qcow2,sparse=true,bus=virtio \
--virt-type=kvm \
--accelerate \
--hvm \
--cdrom=/tmp/ubuntu-22.04.2-live-server-amd64.iso \
--os-type=linux \
--os-variant=generic \
--graphics=spice \
--input=tablet \
--network=network=default,model=virtio \
--video=qxl \
--noreboot
3. Complete the installation steps. Reboot the VM.
Run the test:
1. Detach the network interface so that the test starts with no
interfaces attached:
$ virsh detach-interface $VM network
2. In the VM, write a network config for all en* links to use DHCP:
$ cat > /etc/systemd/network/10-dhcp.network << EOF
[Match]
Name=en*
[Network]
DHCP=yes
EOF
3. Restart systemd-networkd:
$ systemctl restart systemd-networkd
4. On the host, attach an interface to the VM on the no-dhcp network,
so that an IP is not assigned:
$ virsh attach-interface $VM network no-dhcp
5. Back in the VM, confirm that the device is in the
degraded/configuring state:
$ networkctl
networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
8 ens3 ether degraded configuring
2 links listed.
6. Run systemd-networkd-wait-online --any, and confirm that it does
timeout instead of returning while the device is is still not
configured:
$ /lib/systemd/systemd-networkd-wait-online --any --timeout=10
Timeout occurred while waiting for network connectivity.
7. Confirm that the device is STILL in the degraded/configuring state:
$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
8 ens3 ether degraded configuring
2 links listed.
8. Now, leave systemd-network-wait-online --any running while we
attach another interface:
$ /lib/systemd/systemd-networkd-wait-online --any --timeout=0
9. On the host, attach another interface to the VM on the default
network, so that DHCP assigns the interface an IP:
$ virsh attach-interface $VM network default
10. Back in the VM, the systemd-networkd-wait-online process should
have exited with success, and networkctl should show the new link as
configured, while the old one is still configuring:
$ /lib/systemd/systemd-networkd-wait-online --any --timeout=0
$ echo $?
0
$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
8 ens3 ether degraded configuring
9 ens9 ether routable configured
3 links listed.
[Where problems could occur]
This patch we want to remove is totally confined to systemd-networkd-
wait-online, so that's where we would see problems. From what I can
tell, the patch is no longer doing what it was intended to do. E.g.
running systemd-networkd-wait-online on a desktop install, where
systemd-networkd does not manage links, results in a timeout. It only
works with the --any flag, but the --any flag did not exist when the
patch was written. If a user was relying on --any to make systemd-
networkd-wait-online exit when no links are managed, they will see a
change in behavior as a result of this change. However, the resulting
behavior will be consistent with the manual page.
[Original Description]
Ubuntu's packaging of systemd-networkd-wait-online includes a patch
(UBUNTU-wait-online-exit-if-no-links-are-managed) intended to exit if
none of the present links are managed by systemd-networkd. However,
the patch fails to identify links in the "configuring" state, which
implies they are managed, but not yet fully online. This undermines
the purpose of systemd-networkd-wait-online with the --any option,
since at the time the systemd-networkd-wait-online service is started,
managed links are _likely_ in a configuring, but-not-yet-configured
state.
Please see the attached patch. Thanks!
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/+subscriptions
More information about the foundations-bugs
mailing list