systemd-networkd-wait-online should know if there is anything to wait for

[xnox@xxxxxxxxxx (Dimitri John Ledkov)]

On 27 March 2018 at 10:22, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> Dimitri John Ledkov wrote on 26/03/18 11:34:
>> Hello,
>>
>> 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
>> /etc/systemd/network/*.network files.
>>
>> The use cases when it matters:
>>
>> - 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
are awesome.

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
ConditionDirectoryNotEmpty=|/etc/systemd
ConditionDirectoryNotEmpty=|/run/systemd

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

-- 
Regards,

Dimitri.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-wait-online-exit-if-no-links-are-managed.patch
Type: text/x-patch
Size: 1617 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20180328/1a714440/attachment.bin>