units: Drop Also= for systemd-networkd-wait-online.service from systemd-networkd.service #39136
Conversation
…md-networkd.service Enabling systemd-networkd does not mean we're using it to manage host network interfaces, it might be enabled purely to manage network interfaces for containers and virtual machines. Hence, enabling systemd-networkd-wait-online.service, which waits for at least a single network interface managed by networkd to come online is wrong, since enabling systemd-networkd.service does not imply that it is managing a network interface that comes online during boot. Another possible fix is to change systemd-networkd-wait-online to wait for any interface to come online, including unmanaged ones. But if the current behavior is intended, then we cannot enable the service if we enable networkd.
|
cc @yuwata |
github-actions
bot
added
units
please-review
|
@DaanDeMeyer nah. enabling systemd-networkd-wait-online.service does not mean it will be pulled into it but. It only means that if network-online.target is pulled into the boot, that it then will also be pulled into the boot. The idea is that things like mounts of remote nfs shares pull in network-online.target, and thus we'll wait for network at boot. but otherwise noone should end up with this even if systemd-networkd-wait-online.service is enabled. I presume you ran into this, and for some reason had systemd-networkd-wait-online.service delay your boot? That would mean network-online.target was palled in first, can that be? |
|
I think it is OK to drop the lines. But strictly speaking, it breaks backward compat. Please add NEWS entry about the change. |
But the system interface may be managed by NetworkManager... |
I don't know what the right solution is, but I did ran into this with particleos. In the desktop flavor we currently preset to enable both networkd and network-manager, and the latter has priority since it's a desktop. So any time wait-online is enabled, network-manager's own thing is fine, but networkd times out and fails (failing network-online.target) as it has no interfaces to manage |
|
And we do need both networkd and network-manager enabled, as the former still runs in the initrd for network boots (ddi downloaded on the fly), not sure how to square this circle tbh |
but why was network-online.target pulled in in the first place? |
Why does that even matter? Getting a timeout on the target every time you try to start a unit that pulls it in and you don't happen to have a container or virtual machine running with interfaces managed by networkd seems wrong. |
I started systemd-sysupdate.service which depends on it |
|
Or, maybe exit when NetworkManager-wait-online.service is successfully finished and no interface is explicitly requested to be online by networkd at that time? |
Can't we loosen up systemd-networkd-wait-online.service a little and make it exit whenever any interface comes online, even if unmanaged? It should probably still wait for all managed interfaces to become configured, but the online check could include unmanaged interfaces. |
unmanaged interfaces will not have online state, IIRC. |
I think adding logic specific for network manager in wait-online would be a bad solution. If wait-online.service cannot reasonably detect whether one networkd managed interface will come online or not, I don't think we should enable it by default when we enable networkd. |
|
It is not necessary to NetworkManager specific code. But monitor specified service status and if it successfully finished, we can assume an interface becomes online by the corresponding management service. |
Sure but this is still not generically extensible, we'd have to hardcode services in the systemd-networkd-wait-online.service ExecStart= line, that does not seem great :(. |
|
If it is the way to go, then we should not specify the option in the default unit, as the option should be set with |
|
Why not simply check if there are other units that are wanted-by network-online.target, and if that is the case and there are no interfaces managed by networkd, then exit immediately? That should be the right thing in all cases, and won't require custom configurations |
|
Maybe. But anyway that execution mode should be enabled only when --any. |
Yeah, I think this is a nice approach. This works doesn't have to hardcode anything and will automatically do the right thing. |
keszybz
added
reviewed/needs-rework 🔨
Enabling systemd-networkd does not mean we're using it to manage host network interfaces, it might be enabled purely to manage network interfaces for containers and virtual machines. Hence, enabling systemd-networkd-wait-online.service, which waits for at least a single network interface managed by networkd to come online is wrong, since enabling systemd-networkd.service does not imply that it is managing a network interface that comes online during boot.
Another possible fix is to change systemd-networkd-wait-online to wait for any interface to come online, including unmanaged ones. But if the current behavior is intended, then we cannot enable the service if we enable networkd.