On 13 April 2018 at 16:40, Paul Menzel
<pmenzel+systemd-de...@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.)


> 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

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

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

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


systemd-devel mailing list

Reply via email to