[systemd-devel] getting dns-sd to work

[Johannes Ernst]

Here is what I do:

mkdir /etc/systemd/dnssd
cat > /etc/systemd/dnssd/http.dnssd

(the exact example file from "man systemd.dnssd”, minus leading white space)

systemctl restart systemd-resolved

Then

avahi-browse -a -r

or

systemd-resolve —-service myhost._http._tcp.local

as per man page should show me my service, right? Except that it does not. 
Everything else on my network is there. There is nothing remarkable in the 
journal, and strace confirms that systemd-resolved actually reads the file.

What am I doing wrong?

This is systemd-238.76 on Arch.

Thanks,



Johannes.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[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 
AuthorDate: Mon Dec 11 18:27:49 2017 +
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/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