[avahi] (utils) After 1 cmd, sigint.c:90 assertion fails

[Trent Lloyd]

Hi T,

On 17/09/2009, at 7:41 AM, T Ziomek wrote:

> [Avahi 0.6.25, running on a 2.6.19 kernel on an SOC's ARC core.   
> This is
> a 'uclibc' system, with no MMU, and all executables are linked static-
> ally.]


Thanks for using Avahi!

> I'm having a problem getting a cross-compiled Avahi installation  
> going.
> After running just one of the 'utils' commands (e.g. avahi-publish-ad-
> dress), every subsequent cmd fails the assertion at sigint.c:90.  The
> following illustrates what I see...
>
> On a freshly-rebooted system, in shell 1:
> # dbus-daemon --system
> # avahi-daemon
> Found user 'nobody' (UID 99) and group 'nobody' (GID 99).
> Successfully dropped root privileges.
> avahi-daemon 0.6.25 starting up.
> WARNING: No NSS support for mDNS detected, consider installing nss- 
> mdns!
> Failed to open /etc/resolv.conf: No such file or directory
> Failed to read /usr/local/etc/avahi/services.
> Joining mDNS multicast group on interface eth1.IPv4 with address  
> 172.18.2.250.
> New relevant interface eth1.IPv4 for mDNS.
> Joining mDNS multicast group on interface eth0.IPv4 with address  
> 10.2.160.10.
> New relevant interface eth0.IPv4 for mDNS.
> Network interface enumeration completed.
> Registering new address record for 172.18.2.250 on eth1.IPv4.
> Registering new address record for 10.2.160.10 on eth0.IPv4.
> Registering HINFO record with values 'ARC'/'LINUX'.
> Server startup complete. Host name is ARCLinux.local. Local service  
> cookie is 3358135087.
> [nothing further]
>
> In [new] shell 2:
> # avahi-publish-address foo.local 10.2.160.10
> Failed to add address: Local name collision


The name collision that is actually happening here, I suspect, is for  
the reverse DNS of 10.2.160.10 which publish-address adds automatically.

> # avahi-publish-address foo.local 10.2.160.10
> avahi-publish-address: sigint.c: 90: sigint_install: Assertion  
> `pipe_fds[0] == -1 && pipe_fds[1] == -1' failed.
> Aborted
>
> The same assertion fails if the 2nd avahi-tools command issued is  
> some-
> thing else such as "avahi-publish-service".
>
> Now, the "local name collision" is something I also have to solve [1],
> but my immediate concern is the fact that only the first Avahi utils  
> cmd
> run after a reboot gets past this assertion.
>
> [1]:  How can a name collision occur when that name is not  
> configured or
>      set anywhere?

This sounds like some kind of bug.. I'll have to debug further..  
perhaps you can pop into #avahi some time.  Don't have time to think  
about it right now sorry.

Thanks,
Trent