Applications can't connect to avahi-daemon until avahi is restarted once.

I can confirm that this effects me as well. Running current Feisty.

I think this is not really a gajim bug, but an avahi/packaging one. I can't connect using avahi-discover, service-discovery-applet or avahi-publish. All these work, after restarting avahi-daemon. I have these problems after installing a bare ubunutu feisty from cd.

Just tested it. You seem to be correct that this does not only happen with gajim (It just was the only application I noticed this with.
I changed the summary.

I got exactly the same problem with telepathy-salut on Feisty. I have to manually restart avahi-daemon and then it works just fine.

It looks like avahi.daemon gets stuck while registering
(well, I know this is not really a good way of debugging at all, maybe someone has better suggestions?)

Directly after booting:

stefan@silmaril:~$ ps axf | grep avahi
 5431 ? Ss 0:00 avahi-daemon: registering [silmaril.local]
 5432 ? Ss 0:00 \_ avahi-daemon: chroot helper
 6418 pts/0 S+ 0:00 \_ grep avahi

stefan@silmaril:~$ sudo /etc/init.d/avahi-daemon restart
 * Restarting Avahi mDNS/DNS-SD Daemon: avahi-daemon [ OK ]

stefan@silmaril:~$ ps axf | grep avahi
 6533 pts/0 S+ 0:00 \_ grep avahi
 6525 ? Ss 0:00 avahi-daemon: running [silmaril.local]
 6526 ? Ss 0:00 \_ avahi-daemon: chroot helper

(after restarting, all apps using avahi work again)

I just tried and as far as I can tell this bug is not present in gutsy.
So if there is no chance to get a fix in feisty this bug should probably be closed.
But if this chance exists there is still some work to be done tracking down the change that fixed it.
Candidates are as far as I can tell:
1. avahi-daemon is started in a different way. It is invoked in a script that is in turn started by a if-up-hook (this starts avahi-daemon directly in feisty). This scripts also do checks differently compared to the feisty version, but I couldn't find anything that looks suspicious.
2. Some change in some other part of avahi-daemon.

This appears to be fixed in current Gutsy.

I do appear to have the same issue under current gutsy.

Still seems present in hardy as well.

This bug was fixed in the package avahi - 0.6.22-2ubuntu2

---------------
avahi (0.6.22-2ubuntu2) hardy; urgency=low

  * debian/patches/01_avahi-daemon.conf.patch: Disable IPv6 by default again.
    It is not supported/recommended by upstream yet. (LP: #116984)

 -- Martin Pitt <email address hidden> Fri, 07 Mar 2008 09:02:13 +0100

the change fix issues but not likely this one

Had same problem in Feisty
Still have same problem in Gutsy current (dist-upgraded Feisty --> Gutsy)

This is not limited to Gajim, as others have said

My avahi services do not get started reliably. Sometimes, after rebooting, they start. 4 out of 5 times, they do not. I will give some outputs of relevant logs for when they start and when they don't start below.

First, a workaround or solution until this gets fixed:
I found that restarting the avahi services using "/etc/init.d/avahi-daemon restart" did NOT help
Just by luck, I noticed that if I modify /etc/avahi/avahi-daemon.conf, the daemon detects this change and reloads itself. After reloading, my services work properly.
So, I added a simple command "sleep 2 && touch /etc/avahi/avahi-daemon.conf" to the 'start' case of /etc/init.d/avahi-daemon (line 56), as shown below:

d_start() {
    modprobe capability >/dev/null 2>&1 || true

    $DAEMON -c && return 0

    if [ -e ${DISABLE_TAG} ]; then
      # Disabled because of the existance of an unicast .local domain
      log_warning_msg "avahi-daemon disabled because there is a unicast .local domain"
      exit 0;
    fi;

    $DAEMON -D

    ## Added to force reload of avahi-daemon.conf and therefore reliable establishment of services
    sleep 2 && touch /etc/avahi/avahi-daemon.conf
    ## End added command

}

Now my syslog looks like this (and services work):
pr 5 16:59:00 mythtvbox avahi-daemon[13843]: Leaving mDNS multicast group on interface eth1.IPv4 with address 192.168.2.119.
Apr 5 16:59:01 mythtvbox kernel: [ 3159.321157] Failure registering capabilities with primary security module.
Apr 5 16:59:01 mythtvbox avahi-daemon[14103]: Found user 'avahi' (UID 105) and group 'avahi' (GID 111).
Apr 5 16:59:01 mythtvbox avahi-daemon[14103]: Successfully dropped root privileges.
Apr 5 16:59:01 mythtvbox avahi-daemon[14103]: avahi-daemon 0.6.20 starting up.
Apr 5 16:59:01 mythtvbox avahi-daemon[14103]: Successfully called chroot().
Apr 5 16:59:01 mythtvbox avahi-daemon[14103]: Successfully dropped remaining capabilities.
Apr 5 16:59:01 mythtvbox avahi-daemon[14103]: Loading service file /services/afpd-guest.service.
Apr 5 16:59:01 mythtvbox avahi-daemon[14103]: Loading service file /services/afpd-reg.service.
Apr 5 16:59:01 mythtvbox avahi-daemon[14103]: Loading service file /services/samba.service.
Apr 5 16:59:01 mythtvbox avahi-daemon[14103]: Joining mDNS multicast group on interface eth1.IPv4 with address 192.168.2.119.
Apr 5 16:59:01 mythtvbox avahi-daemon[14103]: New relevant interface eth1.IPv4 for mDNS.
Apr 5 16:59:01 mythtvbox avahi-daemon[14103]: Network interface enumeration completed.
Apr 5 16:59:01 mythtvbox avahi-daemon[14103]: Registering new address record for fe80::2a0:ccff:fed0:b6ca on eth0.*.
Apr 5 16:59:01 mythtvbox avahi-daemon[14103]: Registering new address record for fe80::20e:a6ff:fe9f:c091 on eth1.*.
Apr 5 16:59:01 mythtvbox avahi-daemon[14103]: Registering new address record for 192.168.2.119 on eth1.IPv4.
Apr 5 16:59:01 mythtvbox avahi-daemon[14103]: Server startup complete. Host name is mythtvbox.local. Local service cookie is 2787383504.
Apr 5 16:59:01 mythtvbox avahi-daemon[14103]: Re...

One more update:

I reverted to Feisty (for another reason) and tried employing the workaround in /etc/init.d/avahi-daemon described above. It did not work! Avahi-daemon did not detect the file change, so it did not reload itself, and the services were not "successfully established".

However, running "invoke-rc.d avahi-daemon reload" did work.

I seem to have this problem on Hardy (tested with avahi-discover and Gajim).

Reproduced this issue on Hardy.

Screen shot with (slightly) more info enclosed.

Ubuntu 8.10
avahi-daemon 0.6.23

If the service provider is started after the client ( Ubuntu or Windows XP) services are discovered. But if the service provider is already running then no services are discovered when the client fires up.

"invoke-rc.d avahi-daemon reload" on provider allows service discovery

Removing entries from services directory means service disappears from client almost instantly. Contrawise adding the service definition makes the service appear.

Starting GAIM with a Bonjour user ( on the service provider) , the user appears in GAIM on Windows or another Ubuntu; but the user disappears after a few minutes.

Ubuntu 8.10
avahi-daemon 0.6.23

same behavior here, disappears after a few minutes.
fyi, strange behavior in addition to ssh, if the daemon is running ssh establishment takes like 5 seconds.
if its stopped it doesn't take a blink to ask for pw, it's almost instantly.

i couldn't get in touch with the devs, noone answered on irc.
maybe this bug is fixed in the present 0.6.24

Sebastain,

I have heard nothing on this bug - disappointing. I will try again when I
have a chance to upgrade.

On Wed, Feb 25, 2009 at 1:22 AM, sebastianmarkow <email address hidden>wrote:

> Ubuntu 8.10
> avahi-daemon 0.6.23
>
> same behavior here, disappears after a few minutes.
> fyi, strange behavior in addition to ssh, if the daemon is running ssh
> establishment takes like 5 seconds.
> if its stopped it doesn't take a blink to ask for pw, it's almost
> instantly.
>
> i couldn't get in touch with the devs, noone answered on irc.
> maybe this bug is fixed in the present 0.6.24
>
> --
> Applications can't connect to avahi-daemon until avahi is restarted once.
> https://bugs.launchpad.net/bugs/116984
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I upgraded to Jaunty and it happens again, In intrepid worked ok.

This is the log in syslog

http://paste.ubuntu.com/145289/

I had this problem. After some digging, it turned out it was simply a problem of python-avahi not being installed. After installation, it seems to have resolved itself.

Since gajim without python-avahi isn't really a charm, why isn't python-avahi at least recommended (or depended) by gajim? (Now it's just suggested, which AFAIK isn't pulled in automatically by apt)

Same problem here on Jaunty. This problem is quite new for me, as I'm using DAAP (i.e. mt-daapd or Firefly media server) since a couple of years and I the problem was not occurring with previous versions (Intrepid and others).

Can you paste your syslog entries for Avahi following a bad startup and successful daemon restart?

From davebv's syslog, it appears that avahi-daemon is being started before an IP address has been assigned to the machine. That's a startup ordering issue (and secondarily a weakness in Avahi's ability to detect changes to the network configuration). That may or may not be the same problem you are experiencing.

Regarding my above comment, I think I read that log a little too quickly. avahi-autoipd is detecting a Zeroconf address but this is after registering the correct IP on eth0, so this should work fine.

In addition to the relevant entries from your syslog, could you also say which NIC you're using?

My NIC is an Atheros AR928X using the ath9k driver.

Heres my syslog after a bad startup:

May 11 06:25:11 ml-linux NetworkManager: <info> starting...
May 11 06:25:11 ml-linux avahi-daemon[3060]: Found user 'avahi' (UID 108) and group 'avahi' (GID 120).
May 11 06:25:11 ml-linux avahi-daemon[3060]: Successfully dropped root privileges.
May 11 06:25:11 ml-linux avahi-daemon[3060]: avahi-daemon 0.6.23 starting up.
May 11 06:25:11 ml-linux avahi-daemon[3060]: Successfully called chroot().
May 11 06:25:11 ml-linux avahi-daemon[3060]: Successfully dropped remaining capabilities.
May 11 06:25:11 ml-linux NetworkManager: <info> (eth0): new Ethernet device (driver: 'r8169')
May 11 06:25:11 ml-linux NetworkManager: <info> (eth0): exported as /org/freedesktop/Hal/devices/net_00_1e_68_f5_0d_98
May 11 06:25:11 ml-linux NetworkManager: <info> (wlan0): driver supports SSID scans (scan_capa 0x01).
May 11 06:25:11 ml-linux NetworkManager: <info> (wlan0): new 802.11 WiFi device (driver: 'ath9k')
May 11 06:25:11 ml-linux NetworkManager: <info> (wlan0): exported as /org/freedesktop/Hal/devices/net_00_23_4d_56_ff_02
May 11 06:25:11 ml-linux NetworkManager: <info> Trying to start the supplicant...
May 11 06:25:11 ml-linux NetworkManager: <info> Trying to start the system settings daemon...
May 11 06:25:11 ml-linux avahi-daemon[3060]: No service file found in /etc/avahi/services.
May 11 06:25:11 ml-linux avahi-daemon[3060]: Network interface enumeration completed.
May 11 06:25:11 ml-linux avahi-daemon[3060]: Registering HINFO record with values 'I686'/'LINUX'.
May 11 06:25:11 ml-linux avahi-daemon[3060]: Server startup complete. Host name is ml-linux.local. Local service cookie is 265270164.
May 11 06:25:11 ml-linux mt-daapd[2955]: Client running
May 11 06:25:11 ml-linux mt-daapd[2955]: Client registering
May 11 06:25:11 ml-linux mt-daapd[2955]: Client running
May 11 06:26:13 ml-linux dhclient: Internet Systems Consortium DHCP Client V3.1.1
May 11 06:26:13 ml-linux dhclient: Copyright 2004-2008 Internet Systems Consortium.
May 11 06:26:13 ml-linux dhclient: All rights reserved.
May 11 06:26:13 ml-linux dhclient: For info, please visit http://www.isc.org/sw/dhcp/
May 11 06:26:13 ml-linux dhclient:
May 11 06:26:13 ml-linux avahi-daemon[3060]: Registering new address record for fe80::223:4dff:fe56:ff02 on wlan0.*.
May 11 06:26:14 ml-linux NetworkManager: <info> DHCP: device wlan0 state changed (null) -> preinit
May 11 06:26:14 ml-linux dhclient: Listening on LPF/wlan0/00:23:4d:56:ff:02
May 11 06:26:14 ml-linux dhclient: Sending on LPF/wlan0/00:23:4d:56:ff:02
May 11 06:26:14 ml-linux dhclient: Sending on Socket/fallback
May 11 06:26:17 ml-linux dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3
May 11 06:26:18 ml-linux dhclient: DHCPOFFER of 192.168.1.101 from 192.168.1.1
May 11 06:26:18 ml-linux dhclient: DHCPREQUEST of 192.168.1.101 on wlan0 to 255.255.255.255 port 67
May 11 06:26:18 ml-linux dhclient: DHCPACK of 192.168.1.101 from 192.168.1.1
May 11 06:26:18 ml-linux dhclient: bound to 192.168.1.101 -- renewal in 37315 seconds.
May 11 06:26:18 ml-linux NetworkManager: <info> DHCP: device wlan0 state changed preinit -> bo...

Hmm, that looks OK.

All I can think of is that mt-daapd registers with Avahi after it starts but before it has registed an address record (due to the late DHCP). On my system mt-daapd registers after Avahi has registered addesses.

One would expect Avahi to handle this gracefully but I am not entirely familiar with the protocol. Does restarting mt-daapd rather than Avahi fix the problem?

... Yes, restarting mt-daapd (without restarting Avahi) fixes the problem... So maybe the problem is not related to the current bug report...?

As for the NIC, I doubt it is the cause of the problem, since I'm experiencing the problem on 2 machines, with 2 different NICs (one using ath9k driver and the other, the b3 driver). There was no problem with neither machine prior to Jaunty upgrade.

Thanks for testing that.

This means it is likely that the problem lies with Avahi or in miscommunication between mt-daapd and Avahi. The problem seems to be this:

1) Avahi starts up.
2) mt-daapd connects and advertises its service.
3) DHCP assigns an IP to the system.
4) Avahi acknowledges the IP change.
5) [mt-daapd does not get readvertised on the right IP]

It happens to work when you restart Avahi because:

1) mt-daapd disconnects from the stopped service.
2) Avahi starts up and registers on the available IPs.
3) mt-daapd connects and advertises its service.

(The ordering of 2 and 3 is unsafe).

Or when you restart mt-daapd because:

1) mt-daapd connects and advertises its service.

The question of which daemon is at fault is not clear. I will take a closer look at the API tonight to determine which is the case, and plan an appropriate fix either way.

The bad news is I wasn't able to reproduce this last night.

To simulate the problem, I did:

1) /etc/init.d/mt-daapd stop
2) /etc/init.d/avahi-daemon stop
3) /etc/init.d/networking stop

4) /etc/init.d/avahi-daemon start
5) /etc/init.d/mt-daapd start

(At this point, mt-daapd is registered but not on the Ethernet link.)

6) /etc/init.d/networking start

I was then hoping that avahi-daemon would register the new interface but that the DAAP service would not be visible on the network. This wasn't the case, however, and mt-daapd appeared in a client machine's media player as soon as Avahi had done its thing. mt-daapd didn't need to disconnect or reregister.

When I take my laptop home on Saturday I will try and reproduce this with a wireless connection. It's an Intel PRO/Wireless interface, so not a perfect match to your ath9k NIC, but it might exhibit similar problems. Without a reproduce this would be quite hard to fix, unfortunately.

Right, I've tried to reproduce this with the help of my laptop. After configuring it to make a wireless connection (with the iwl3945 Intel PRO/Wireless driver) on boot, outside of NetworkManager, and installing patched mt-daapd it successfully appears on a wired client's shared library list in Rhythmbox from a fresh boot.

Relevant lines of the syslog look like this:

May 16 16:13:59 ceres dhclient: Listening on LPF/wlan0/00:1c:bf:90:a4:c0
May 16 16:13:59 ceres dhclient: Sending on LPF/wlan0/00:1c:bf:90:a4:c0
May 16 16:13:59 ceres dhclient: Sending on Socket/fallback
May 16 16:13:59 ceres dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
May 16 16:13:59 ceres kernel: [ 17.384085] wlan0: authenticate with AP ffff88007d0bfac0
May 16 16:13:59 ceres kernel: [ 17.385975] wlan0: authenticated
May 16 16:13:59 ceres kernel: [ 17.385980] wlan0: associate with AP ffff88007d0bfac0
May 16 16:13:59 ceres kernel: [ 17.388574] wlan0: RX AssocResp from ffff88007d951026 (capab=0x411 status=0 aid=1)
May 16 16:13:59 ceres kernel: [ 17.388580] wlan0: associated
May 16 16:13:59 ceres kernel: [ 17.390822] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
May 16 16:13:59 ceres mt-daapd[2753]: Firefly Version svn-1696: Starting with debuglevel 2
May 16 16:13:59 ceres mt-daapd[2753]: Error loading plugin /usr/lib/mt-daapd/plugins/ssc-ffmpeg.so: /usr/lib/mt-daapd/plugins/ssc-ffmpeg.so: undefined symbol: avcodec_decode_audio
May 16 16:13:59 ceres mt-daapd[2753]: Error loading plugin /usr/lib/mt-daapd/plugins/ssc-script.so: plugin declined to load
May 16 16:13:59 ceres mt-daapd[2753]: Plugin loaded: daap/svn-1696
May 16 16:13:59 ceres mt-daapd[2753]: Plugin loaded: rsp/svn-1696
May 16 16:13:59 ceres mt-daapd[2753]: Starting signal handler
May 16 16:13:59 ceres mt-daapd[2760]: Starting rendezvous daemon
May 16 16:13:59 ceres mt-daapd[2760]: Client connecting
May 16 16:14:00 ceres mt-daapd[2760]: Initializing database
May 16 16:14:00 ceres mt-daapd[2760]: Full reload...
May 16 16:14:00 ceres avahi-daemon[2813]: Found user 'avahi' (UID 110) and group 'avahi' (GID 119).
May 16 16:14:00 ceres avahi-daemon[2813]: Successfully dropped root privileges.
May 16 16:14:00 ceres avahi-daemon[2813]: avahi-daemon 0.6.23 starting up.
May 16 16:14:00 ceres avahi-daemon[2813]: Successfully called chroot().
May 16 16:14:00 ceres avahi-daemon[2813]: Successfully dropped remaining capabilities.
May 16 16:14:00 ceres acpid: client connected from 2785[0:0]
May 16 16:14:01 ceres avahi-daemon[2813]: No service file found in /etc/avahi/services.
May 16 16:14:01 ceres avahi-daemon[2813]: Network interface enumeration completed.
May 16 16:14:01 ceres avahi-daemon[2813]: Registering new address record for fe80::21c:bfff:fe90:a4c0 on wlan0.*.
May 16 16:14:01 ceres avahi-daemon[2813]: Server startup complete. Host name is ceres.local. Local service cookie is 2860126817.
May 16 16:14:01 ceres avahi-daemon[2813]: Registering HINFO record with values 'X86_64'/'LINUX'.
May 16 16:14:01 ceres mt-daapd[2760]: Client running
May 16 16:14:01 ceres mt-daapd[2760]: Client registering
May 16 16:14:03 ceres dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 6...

Thanks a lot jay (jcornwall) for your precious help... My problem might be related to some sort of bad NIC/router/something else combination... (still, it's weird that it happens only since Jaunty upgrade, on 2 machines...)

Anyway, I've found a workaround, with a script that runs at boot to automate the restart of avahi-daemon, so I can live with this for now.

Thanks again.

Similar or same (?) issue here on Karmic 9.10 am64 using avahi for pulseaudio-streaming to an AirportExpress.

Avahi needs a restart of avahi-daemon or restart of network-manager (both works) to resolve the airport.local device.

I have the same issue as Takkat withe pulseaudio-raop module with an airport express. Sometimes pulseaudio will just lose sight of the Airport Express device on the network, and the only way to get it to come back is by restarting avahi or the network.

I'm having no success restarting avahi-daemon or network-manager - I still get nothing with avahi-browse

In lucid RC, restarting avahi-daemon or network-manager don't fix the problem

Still got this issue on Lucid 10.04...I always need to restart avahi-daemon once to see the available services on the network.

Same her on Lucid 10.04 LTS. Maybe this is all related to improper handling updates of available services. My recent report (Bug #586229) puts focus on this but still waits for confirmation. IMHO this bugreport here is dead.

For streaming to an AirportExpress see lp:stream2ip for a GUI to stream directly to the IP without the need for an Avahi name resolution.

Same problem on ubuntu 11.10.

FWIW: We've had problems with avahi-daemon getting stuck in registering on 12.04 and ended up patching it from: http://lists.freedesktop.org/archives/avahi/2014-March/002291.html

Work is available here: http://bazaar.launchpad.net/~lmas/avahi/simpad/revision/107