Dear Dimitri,
Thank you for your quick response. On 04/16/18 12:47, Dimitri John Ledkov wrote:
On 13 April 2018 at 16:40, Paul Menzel wrote:
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
Thank you, no idea, why I didn’t find it with `git log --oneline --graph`. Hmm, looks like, Lennart directly put that commit in master without merging the pull request.
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, potentially, 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 networking.target and network-online.target. This means that resolved is required earlier in the boot cycle. Before networking.target.
Just to be sure, you mean *network.target*, right?Thank you for specifying the requirement. I agree, that it should be started as early as possible, but I disagree with the rest.
There are things that expect network to be up in "network-online.target", which by some is implied to mean DNS resolution too, unfortunately.
Sorry for being ignorant, but could you please be specific, what these things are. If these units have that requirement order them after `network-online.target`.
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
First, I think, the terminology of *early* leads to misunderstandings. For you it includes ordering with `Before=`, for me it’s just about `After=` statements.
Anyway, regressing the user experience for everyone only because it’s required for cloud-init is not right in my opinion. As you pointed out, the system integrator can adapt certain things, and in my opinion, I throw the ball back to you, and kindly ask you, to adapt systemd locally so it works with your use-case or let’s come up with a better solution.
Maybe a new target is needed, where you can order your services after, as ordering them after systemd-resolved.service is too specific.
I submitted a merge/pull request to change the ordering [1]. Kind regards, Paul [1] https://github.com/systemd/systemd/pull/8731
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
