Post by Colin Guthrie Post by Dimitri John Ledkov
When systemd-networkd-wait-online was originally introduced, it was
the only tool that correctly waited and blocked the boot, until after
networking is configured.
These days, however, all/most network configurations tools ship
appropriate wait-online integration. E.g. there is network-manager
wait online service and ifupdown wait online, on Debian/Ubuntu.
These other helpers, seem to be slightly smarter than
systemd-networkd-wait-online. Specifically, all other helpers exit
straight away, if they have no devices configured / managed. Whilst
systemd-networkd-wait-online, doesn't appear to know if it expects any
devices / can manage any devices. Ideally, if no devices are
configured / no devices match .network files, maybe it should exit
straight away? Or for example, do so if no devices are found in
"configuring/pending/not yet processed by udev".
(code wise, it is to change one_ready to true by default, and only
continue blocking the, if there is anything pending configuration).
I'm considering doing this by default, or for-example, doing it if
there are no /run/systemd/network/*.network
- installer ISO booted without any NICs attached
(or NICs require special drivers / firmware loaded etc)
- cloud-image booted and cloud-init failed to find network-config and
generate networkd stanzas
But how do you differentiate a device which is not present vs. one which
is slow to appear?
If the system isn't online then surely any dependant units don't need to
be started anyway. If the system requires being online to operate
properly then all this behaviour is correct.
If you don't use systemd-networkd then you possibly don't want
systemd-networkd-wait-online either and thus it can be happily disabled.
So I don't really appreciate why this is an issue. Unless, you're trying
to use a kind of hybrid environment (e.g. using networkd for wired
networks (perhaps USB dongles) and NetworkManager for wifi and you'd
want networkd-wait-online to be a no-op when the USB dongle is not there?)
I guess it's possible to know if networkd is configured to not manage
any devices *at all*, but perhaps there isn't much point in enabling the
networkd-wait-online service at all in that case anyway?
Struggling to understand the "why" question here, but could easily be
missing something! :-)
The problem is inability to inject systemd-networkd-wait-online into
the initial transaction when one determines that there are interfaces
managed by networkd and thus we should wait for them to be configured.
The inverse problem is - if systemd-networkd-wait-online is enabled,
it blocks boot for way too long, even though nothing is going to
happen - it already runs post udev coldplug/settle, and we shouldn't
be sitting around awaiting for hotplug interfaces to appear (that is
fragile, and they should be marked RequiredForOnline=False)
The system, normally, when fully configured will only use networkd.
But that's upon second boot, and later. On the inital boot, it may
figure out networking information or not. Specifically currently on
Ubuntu cloud images, cloud-init injects itself before the networking
targets and discovers metadata that may (or may not) specify
networking configuration data. Due to inability to inject
systemd-networkd-wait-online as part of the initial transaction, it is
enabled by default. If networking configuration is correctly
discovered - things are awesome, systemd-networkd-wait-online blocks
boot for a short period of time, until networkd is done, and things
If the metadata on the other hand did not contain networking
information.... the boot is blocked for 120s, and there is a lot of
console spew "Awaiting networking to be configured" stuff (which looks
horible on serial consoles) and one is prevented from continuing the
rest of the boot process / getting to the console for the sysadmin to
interactive configure the networking.
Hence I was thinking for systemd-networkd-wait-online to bail out
quicker, e.g. http://paste.ubuntu.com/p/gRBgfzGvSW/ (or see attached)
which quits the loop if there are no links managed by networkd, after
all links finished processing by udev/networkd, and none ended up
being managed by networkd & thus none are awaiting to move from
configured -> (failed, routable/degraded)
However, discussing this more, I wonder, if on Ubuntu (or by default)
systemd-networkd-wait-online.service should have
(which is not quite stateless)
I'm not sure if the interfaces to wait for can be extended (as in pass
eth2 to ExecStart= as an argument via e.g. a drop-in, whilst the boot
transaction is in flight).
Somehow, I would have thought, it should be possible for networkd to
parse it's config, figure out if there are any interfaces configured,
then block on them - or quit straight away.