[avahi] (utils) After 1 cmd, sigint.c:90 assertion fails
Trent Lloyd
lathiat at bur.st
Wed Sep 16 22:04:53 PDT 2009
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
More information about the avahi
mailing list