Published zeroconf service can't be resolved


I just set up Mopidy on a Raspberry Pi running OSMC (Debian Jessie based distribution with preconfigured Kodi).
Everything is working fine, except zeroconf.

The published services, _mopidy-http._tcp and _mpd._tcp are announced but can’t be resolved.
It turns out this is caused by being set to localhost6.localdomain6.local when calling:
                dbus.UInt32(_AVAHI_PUBLISHFLAGS_NONE),, self.stype,
                self.domain,, dbus.UInt16(self.port),

Hence, socket.getfqdn() is returning localhost6.localdomain6.

By manually setting to osmc.local (the “correct” hostname), the published services can be resolved and everything is working just fine.

Any idea what is causing this? Is it a bug in Mopidy or is the osmc system configuration incorrect?


I would check what the hostname command on the machine thinks, and what the /etc/hostname file and possibly /etc/hosts is setup with. As for “solving” this in mopidy, we could a config to override the host name used in zeroconf, but likely the better fix is to make sure that socket.getfqdn() does the right thing on your system.

OK, so not an issue with mopidy then?
It seems the localhost6.localdomain6 is picked up from /etc/hosts:

osmc@osmc:~$ hostname
osmc@osmc:~$ cat /etc/hostname
osmc@osmc:~$ cat /etc/hosts
::1             osmc localhost6.localdomain6 localhost6       osmc       localhost
::1             localhost ip6-localhost ip6-loopback
fe00::0         ip6-localnet
ff00::0         ip6-mcastprefix
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

According to the documentation for socket.getfqdn():

The first name which includes a period is selected.

Then why is socket.getfqdn() looking up the name for ::1?

Maybe it is an issue with mopidy after all.
According to the documentation, calling socket.getfqdn() with no argument results in:

If name is omitted or empty, it is interpreted as the local host.

This together with:

The first name which includes a period is selected.

Should mean publishing the service as localhost6.localdomain6 might happen more often than not on IPv6 enabled systems.

The avahi documentation actually recommends passing NULL as hostname to the C-API because:

We recommend to pass NULL here, the daemon will than automatically insert the local host name in that case

Passing the empty string to the Python wrapper, as suggested in #805 is maybe the solution?

I just realized that I forgot to report back that passing an empty string to AddService, as suggested in the official avahi documentation, results in the backend succesfully publishing the service.

The change, around line 60 in, changed from: = template.safe_substitute(
            hostname=socket.getfqdn(), port=self.port) = '%s.local' % socket.getfqdn()

To: = template.safe_substitute(
            hostname=socket.getfqdn(), port=self.port) = ''

Should I file a bug report in the mopidy issue tracker?
This probably affects more users than myself seeing that the existing code will cause publishing of the mopidy service on localhost6.localdomain6 if it is present in /etc/hosts as described in my previous posts.

Yes, please open an issue and we’ll fix it.

Issue #1283 created