Description of problem:

As mentioned in Bug 1471318, avahi-daemon ignores the  ListenStream=  setting in /usr/lib/systemd/system/avahi-daemon.socket .

 Running:
   strings /lib64/libnss_* /lib/libnss_mdns*|grep avahi 
confirms that the path to the socket, /run/avahi-daemon/socket  is hard-coded into the binaries.

 In most systems this won't give any issues, because most users won't change the default. But narrowing the problem down for some cases is extremely difficult because of this. In my case I ran into this because at some upgrade, when we went from /var/run to /run, it seems I did not end up with a symlink there, and avahi managed to survive with "most" things avahi-related working (avahi-browse -a worked perfectly, for example), but not this one edge case of getent resolution (so it required jumping through iptables hoops to get my printer to print).


Version-Release number of selected component (if applicable):

avahi-0.7-24


How reproducible:

Change ListenStream=  setting in /usr/lib/systemd/system/avahi-daemon.socket to anything other than  /run/avahi-daemon/socket and move the socket to the corresponding new path.


No need to restart avahi, it should immediately fail to resolve "getent" calls.. moving the socket back to the "default" location will also immediately fix the problem, no need to restart avahi.


Steps to Reproduce:
1. 
2.
3.



Actual results:

getent --service=mdns4 hosts MYNODE.local
getent --service=mdns4_minimal hosts MYNODE.local

(and all dependent services) will fail.

But 

avahi-resolve -n MYNODE.local

works and resolves correctly:
MYNODE.local   192.168.0.125





Expected results:

Resolution of MYNODE.local should succeed.