[Bug 1982218] Re: wait-online does not correctly identify managed links

Nick Rosbrook 1982218 at bugs.launchpad.net
Tue Aug 15 15:51:01 UTC 2023 

** Changed in: systemd (Ubuntu Lunar)
       Status: New => Triaged

** 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.
+ 
+ 1. 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:
+ 
+ $ networkctl reload
+ 
+ 3. 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
+ degraded/configuring state:
+ 
+ $ networkctl
+ 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
+ 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:
+ 
+ $ 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!

-- 
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:
  Triaged

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. 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.

  1. 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:

  $ networkctl reload

  3. 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
  degraded/configuring state:

  $ networkctl
  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
  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:

  $ 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