"optional: true" flag introduces problem it's meant to fix in certain circumstances

Bug #2039083 reported by Adam Vest
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
netplan
Triaged
High
Unassigned
systemd (Ubuntu)
New
Undecided
Unassigned

Bug Description

Hello!

This bug is in relation to the situation where the "systemd-networkd-wait-online.service" hangs for several minutes on boot before eventually failing. I guess I don't know if this flag was introduced specifically for this situation, but I do know that one of the fixes for this issue is to add "optional: true" to any non-critical interfaces (as per the docs[1]). While this may be the case, it just so happens that adding this flag to an interface when it's the only configured interface in netplan can actually INTRODUCE the issue as well. Example:

---
:~# grep -Ev "^#" /etc/netplan/50-cloud-init.yaml
network:
    version: 2
    ethernets:
        enp5s0:
            dhcp4: true
            optional: true
---

The above config will cause the service hang/failure, and the removal of the flag will resolve the issue. I primarily opened this bug report with the idea that we might update aforementioned documentation to include a caveat that you want to avoid adding this flag to the only configured interface. However, it was also discussed that we might consider having the netplan config parser complain about such a setup and consider it invalid, which it kinda is. I believe in a situation where you may have a server that should have NO network connectivity, you would simply leave netplan unconfigured and/or stop any relevant services, rather than try to configure all interfaces as optional.

My original test was on Jammy, though I tested this also on Focal and Bionic, and neither of those appear to be affected by this - setting the only interface as optional in either of those does not cause the "systemd-networkd-wait-online" service to hang and the system boots normally.

Let me know if you'd like/need any more info from me! Thank you!

[1] https://netplan.io/faq#prevent-waiting-for-interface

Revision history for this message
Lukas Märdian (slyon) wrote :

I think this is related to a recent change in behavior in systemd.

It is supposed to be fixed, by implementing the "network-online.target" specification. Which defines what should be waited for: https://discourse.ubuntu.com/t/spec-definition-of-an-online-system/27838

But we first need to get some of the groundwork landed in upstream systemd-networkd.

Changed in netplan:
status: New → Triaged
importance: Undecided → High
tags: added: network-online-ordering
Revision history for this message
Birgit Edel (biredel) wrote :

closely related LP: #2036358
Whatever Ubuntu and systemd decide to do, the manual systemd-networkd-wait-online(8) also needs clarification:

"[..] wait for all links it is aware of and which are
 managed by systemd-networkd.service(8) to be fully configured or
 failed, and for at least one link to be online."

The "and at least one" phrase neither clarifies the previous, arguably preferable, Ubuntu patch - nor how the alternative is supposed to be used, where networkd knows it is not managing anything and goes to sleep(120) anyway, while some other network-online.target dependency might have already finished.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.