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

commit 1f1580139ed48dd308a6a2470baf037ae1ed6aab
Author:     Dimitri John Ledkov <>
AuthorDate: Mon Dec 11 18:27:49 2017 +0000
Commit:     Lennart Poettering <>
CommitDate: Thu Jan 11 12:40:44 2018 +0100

    resolved.service: set DefaultDependencies=no
On systems that only use resolved for name resolution, there are usecases that
    require resolved to be started before sysinit target, such that network name
    resolution is available before network-online/sysinit targets. For example,
    cloud-init for some datasources hooks into the boot process ahead of sysinit
    target and may need network name resolution at that point already.
systemd-resolved already starts pretty early in the process, thus starting it
    slightly earlier should not have negative side effects.
However, this depends on resolved ability to connect to system DBus once that
    is up.

diff --git a/units/ 
index 8059aa7b6..c4c7f1fee 100644
--- a/units/
+++ b/units/
@@ -13,8 +13,10 @@ Documentation=man:systemd-resolved.service(8)
+After=systemd-sysusers.service systemd-networkd.service

I like starting systemd-resolved earlier, but unfortunately ordering it before `` adds a delay on systems wanting to start as fast as possible. But why did you change it from `` to ``? I’d say `` 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.
           This unit is supposed to indicate when network functionality is
           available, but it is only very weakly defined what that is supposed
           to mean, with one exception: at shutdown, a unit that is ordered
           after will be stopped before the network — to
           whatever level it might be set up then — is shut down. It is hence
           useful when writing service files that require network access on
           shutdown, which should order themselves after this target, but not
           pull it in. Also see Running Services After the Network is up[1]
           for more information. Also see described

           systemd automatically adds dependencies of type After= for this
           target unit to all SysV init script service units with an LSB
           header referring to the "$network" facility.
           Units that strictly require a configured network connection should
           pull in (via a Wants= type dependency) and
           order themselves after it. This target unit is intended to pull in
           a service that delays further execution until the network is
           sufficiently set up. What precisely this requires is left to the
           implementation of the network managing service.

           Note the distinction between this unit and This
           unit is an active unit (i.e. pulled in by the consumer rather than
           the provider of this functionality) and pulls in a service which
           possibly adds substantial delays to further execution. In contrast,
  is a passive unit (i.e. pulled in by the provider of
           the functionality, rather than the consumer) that usually does not
           delay execution much. Usually, is part of the boot
           of most systems, while is not, except when at
           least one unit requires it. Also see Running Services After the
           Network is up[1] for more information.

           All mount units for remote network file systems automatically pull
           in this unit, and order themselves after it. Note that networking
           daemons that simply provide functionality to other hosts generally
           do not need to pull this in.

           Note that this unit is only useful during the original system
           start-up logic. After the system has completed booting up, it will
           not track the online state of the system anymore. Due to this it
           cannot be used as a network connection monitor concept, it is
           purely a one-time system start-up concept.

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.

Kind regards,



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

systemd-devel mailing list

Reply via email to