[systemd-devel] Changed ordering of systemd-resolved.service

[Paul Menzel]

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 <xnox at ubuntu.com>
> AuthorDate: Mon Dec 11 18:27:49 2017 +0000
> Commit:     Lennart Poettering <lennart at poettering.net>
> 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/systemd-resolved.service.in b/units/systemd-resolved.service.in
> index 8059aa7b6..c4c7f1fee 100644
> --- a/units/systemd-resolved.service.in
> +++ b/units/systemd-resolved.service.in
> @@ -13,8 +13,10 @@ Documentation=man:systemd-resolved.service(8)
>  Documentation=https://www.freedesktop.org/wiki/Software/systemd/resolved
>  Documentation=https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
>  Documentation=https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
> -After=systemd-networkd.service network.target
> -Before=network-online.target nss-lookup.target
> +DefaultDependencies=no
> +After=systemd-sysusers.service systemd-networkd.service
> +Before=network.target nss-lookup.target shutdown.target
> +Conflicts=shutdown.target
>  Wants=nss-lookup.target
>  
>  [Service]

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.

>        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 network.target 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 network-online.target described
>            above.
> 
>            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.

>        network-online.target
>            Units that strictly require a configured network connection should
>            pull in network-online.target (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 network.target. 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,
>            network.target 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, network.target is part of the boot
>            of most systems, while network-online.target 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,

Paul


[1] 
https://github.com/systemd/systemd/commit/1f1580139ed48dd308a6a2470baf037ae1ed6aab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5174 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20180413/d29e6d90/attachment.bin>