order systemd-resolved.service before nss-lookup.target

[ReubenM]

I'm trying to fix issues with some services that try to read /etc/resolv.conf when they start up. The issue I'm running into is that if /etc/resolve.conf is soft-linked to /run/systemd/resolve/resolv.conf then it is often the case that the resolver service has not yet generated its resolve.conf yet and the softlink is left pointing nowhere.

Two services that I'm currently aware of that I'm having problems with are the nscd services and avahi.

I was advocating adding an "After=systemd-resolved.service" to those services, but I'm told a better more universal means of fixing that is to use the nss-lookup.target. But systemd-resolved.service would need to be a member of that target.

For reference: https://bugs.gentoo.org/show_bug.cgi?id=556602

[floppym]

Two services that I'm currently aware of that I'm having problems with are the nscd services and avahi.

In the specific case of nscd, I would guess that After=nss-lookup.target is a bad fit since nscd also provides nss-related services. I was thinking more in the general case.

[poettering]

hmpf. not sure i like this. We carefully made sure that we have nice fallback paths in nss-resolve to use the old dns NSS modules if resolved is not around, in order to avoid syncing on resolved.

This really sounds like something to fix in avahi and nscd though, no?

[ReubenM]

I'm not certain which is "correct". This bug is more for soliciting advice than anything else.
We can add the "After=systemd-resolved.service" line to avahi-daemon and nscd service files, but were not certain if that would be best practice.

[poettering]

What precisely is the broken behaviour from avahi/nscd you get right now?

[ReubenM]

avahi service log:

avahi-daemon[433]: chroot.c: open() failed: No such file or directory
avahi-daemon[401]: Failed to open /etc/resolv.conf: Invalid argument

nscd service log

nscd[419]: 419 cannot stat() file `/etc/resolv.conf': No such file or directory

These error messages clear up if loaded after systemd-resolved. For avahi, I've noticed the search domain is not appended under wide-area. (unless you manually reload the service) For nscd I'm not certain if it effects cache functionality or not.

[poettering]

i wonder if we should simply add an "f /etc/resolv.conf" or so as tmpfiles snippet to the avahi pkg...

[ReubenM]

crazy idea: what if /etc/resolve was a normal file instead of a soft-link. The default config for when no service is managing it. And then systemd-resolved bind mounts /run/systemd/resolve/resolv.conf to /etc/resolve.conf after it's loaded using a resolve.mount unit file configured to load after systemd-resolved. The mount unit could then be masked depending on if such a feature is desired or not.

No doubt that probably presents all kinds of issues I haven't considered, but it gets rid of the problem of a dead-end soft link for anything hardwired to read /etc/resolv.conf that is loaded before the resolved service.

[ReubenM]

meh. Tried it just to see what would happen. TIL that ownership of and access to /run/systemd/resolve/resolv.conf changes depending on the presence (or lack thereof) of the /etc/resolve.conf soft link.

[aletheia7]

Similiar problem filed with Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800643

Dependency issue with avahi-daemon and systemd-resolved and /etc/resolv.conf

[mbiebl]

2015-08-05 21:42 GMT+02:00 Lennart Poettering notifications@github.com:

i wonder if we should simply add an "f /etc/resolv.conf" or so as tmpfiles
snippet to the avahi pkg...

The problem is that /etc/resolv.conf is a dangling symlink as long as
systemd-resolved has not yet been started.
Creating /etc/resolv.conf as real file will break the use of systemd-resolved.

Did you maybe mean to ship a tmpfiles snippet to create
/run/systemd/resolve/resolv.conf ?

This would ensure that the symlink is not dangling (even though the file pointed to would be empty)
earlier during the boot process.

Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[mbiebl]

That said, shouldn't we try to start systemd-resolved earlier during boot by using DefaultDependencies=no to have resolvable names as soon as possible?

[cjk]

Same problem here. In addition to the above mentioned avahi-service, my dnsmasq-service (which is also trying to read /etc/resolv.conf) is failing about 75% of bootups, probably in a race-condition with systemd-resolved.

[bcomnes]

Also seeing spurious errors on startup that @ReubenM described on archlinux-arm triggered by avahi 0.6.32rc-1.

[pmattern]

i wonder if we should simply add an "f /etc/resolv.conf" or so as tmpfiles snippet to the avahi pkg...

I dare say please don't.
Each time I personally stumbled upon that error message open() failed: [...] of avahi-daemon there was in fact something wrong with resolv.conf due to problems of other components, e. g. ConnMan on Arch Linux just recently.
A tmpfiles snippet as proposed above could mask problems like that and hence eventually prevent them from getting fixed.

[Paviluf]

I see these error too on Fedora 24

juil. 10 12:19:55 Desktop avahi-daemon[638]: chroot.c: open() failed: No such file or directory
juil. 10 12:19:55 Desktop avahi-daemon[617]: Failed to open /etc/resolv.conf: Invalid argument

Don't know if it's related but Avahi doesn't seem to work on Fedora 24

http://www.forums.fedoraforum.org/showthread.php?p=1766149
https://bugzilla.redhat.com/show_bug.cgi?id=1354080
lathiat/avahi#52

Thanks !

[MeisterP]

Since newer versions of networkmanager use a symlink too, this is no longer only a systemd-resolved issue.
/etc/resolv.conf -> /run/NetworkManager/resolv.conf

[m8ram]

@Paviluf : I see the same error on Fedora 24. If I restart avahi-daemon after NetworkManager was started it no longer reports the error.
Perhaps that helps with the avahi issues you experience?
Regards

[emilefromparis]

hi I just comment the line where i wrote the ip adress of my client
#listen-address=127.0.0.1,192.168.1.3
and then the server restart normally
like one can see on
systemctl -l status dnsmasq.service
best regards