If doing things the systemd way and using it's resolver service, /etc/resolv.conf is supposed to be a soft link to /run/systemd/resolve/resolv.conf. However, if the resolver service has not yet had time to generated its resolv.conf file, the softlink doesn't resolve (no word play intended) to anything. Any service trying to access that file will fail in different ways to load correctly. For some services it might simply result in an inert error msg, for others it alters functionality. Such services need to have the following added to the "[Unit]" section of their service file: After=systemd-resolved.service There may be others, but currently I'm aware of two services so far that need this: nscd.service (sys-libs/glibc) avahi-daemon.service (net-dns/avahi) The added line to the service files should be harmless to anybody not using systemd's resolver service. Reproducible: Always
nss-lookup.target seems like a better fit for this. nss-lookup.target A target that should be used as synchronization point for all host/network name service lookups. Note that this is independent of user/group name lookups for which nss-user-lookup.target should be used. All services for which the availability of full host/network name resolution is essential should be ordered after this target, but not pull it in. 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 "$named" facility. However, systemd-resolved.service is not ordered before nss-lookup.target, so this seems to be broken. That's an issue you might want to ask about upstream.
filed upstream: https://github.com/systemd/systemd/issues/848
Re-reading this, I guess we should distinguish between programs that directly access resolv.conf and those that simply do hostname lookups via glibc. For the former, After=systemd-resolved.service may indeed be a better choice.
