Changed ordering of systemd-resolved.service

[xnox@xxxxxxxxxx (Dimitri John Ledkov)]

On 13 April 2018 at 16:40, Paul Menzel
<pmenzel+systemd-devel at molgen.mpg.de> wrote:
> Dear Dimitri, dear systemd folks,
>
>
> In commit 1f158013 (resolved.service: set DefaultDependencies=no) the
> ordering of systemd-resolved.service was changed. (How do I find the merge
> request to find possible discussion? Also the commit message description is
> too specific in my opinion, as it doesnâ??t give a clue that more is changed.)
>

https://github.com/systemd/systemd/pull/7609

>
> I like starting systemd-resolved earlier, but unfortunately ordering it
> before `network.target` adds a delay on systems wanting to start as fast as
> possible. But why did you change it from `network-online.target` to
> `network.target`? Iâ??d say `network-online.target` is more correct.
>
> For my use case of a fast system start-up, this change delays it by at least
> 100 ms, as now it takes longer to reach the end of the network target.
>

cloud-init initializes networking configuration by fetching,
potentionally, remote sources to customize an instance on first boot.
Specifically it may dhcp any interface, to reach a metadata source,
download the real networking configuration, reconfigure networking to
match the final networking details (all interfaces / public ip
addresses / etc), and proceed to complete netwokring.target and
network-online.target.

This means that resolved is required earlier in the boot cycle. Before
networking.target.

There are things that expect network to be up in
"network-online.target", which by some is implied to mean DNS
resolution too, unfortunately.

>
> If your systems have problems with it, they have wrong dependencies, donâ??t
> they? Also, they should probably be able to deal with the situation, that
> DNS does not work, as that can happen during operation.
>
> So, Iâ??d really like to rework that ordering change.
>

Reworking that change will break certain public cloud providers
unfortunately because of public clouds metadata providers being odd.

Note, we cannot use dbus activation in this case as dbus-daemon is not
up yet, and systemd-resolve command line client also does not work at
this point.

If you want to make it an optional dependency that early, maybe it
will be possible to convert systemd-resolved to be socket activated on
tcp/udp?

Alternatively, as a system integrator, you may want to change these
dependencies in your distro, especially if you do not configure
resolved _stub resolver_ as the default provider of /etc/resolv.conf
or for example to do not use the recommended default stub-provider
over 127.0.0.53 and instead use the nss module over dbus.

The above dependencies are correct and recommend, for the default
setup of /etc/resolv.conf pointing at the stub-resolv.conf as
generated by resolved at runtime.

Specifically, the dependencies as is are "too-early" if one uses the
last two modes of the /etc/resolv.conf handling as described in the
man page - https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#/etc/resolv.conf

-- 
Regards,

Dimitri.