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 <x...@ubuntu.com> AuthorDate: Mon Dec 11 18:27:49 2017 +0000 Commit: Lennart Poettering <lenn...@poettering.net> CommitDate: Thu Jan 11 12:40:44 2018 +0100 resolved.service: set DefaultDependencies=noOn systems that only use resolved for name resolution, there are usecases thatrequire 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 itslightly earlier should not have negative side effects.However, this depends on resolved ability to connect to system DBus once thatis 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 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 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 https://github.com/systemd/systemd/commit/1f1580139ed48dd308a6a2470baf037ae1ed6aab
Description: S/MIME Cryptographic Signature
_______________________________________________ systemd-devel mailing list firstname.lastname@example.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel