You are not logged in.
I seem to have a weird problem of avahi-dnsconfd not starting on boot, but it works fine when started after boot manually.
I spend the last two hours rebooting and modifying my /etc/rc.conf on trial & error, but nothing helped. This is my actual DAEMON line in /etc/rc.conf:
DAEMONS=(syslog-ng !network dhcdbd networkmanager avahi-daemon @avahi-dnsconfd @crond @netfs @nscd @lisa @fam !samba @cups @alsa !esd @cpufreq @powersaved @preload @gensplash kdm)
It's definitely the case, that when the avahi-dnsconfd init-script is run, it can not connect to the avahi-daemon, because it shows this line in /var/log/errors.log:
avahi-dnsconfd[4294]: connect(): No such file or directory
whereas when starting avahi-dnsconfd after booting manually by running 'sudo /etc/rc.d/avahi-dnsconfd start' it's just starting as intended with the following output in /var/log/daemon.log:
avahi-dnsconfd[4376]: Successfully connected to Avahi daemon.
I already tried several different daemin-start-orders in my DAEMON line, but even putting avahi-daemon at last before kdm and removing all '@' did not change anything.
So what am I missing in this scenario?
Last edited by Master One (2007-02-01 18:32:59)
Offline
Some more info to follow:
I just rebooted again, and removed the "@" from the avahi-dnsconfd daemon, so that it reports back its status during boot, and both (so avahi-daemon & avahi-dnsconfd) report [DONE], but when having a look at the running processes, avahi-dnsconfd does not show up and is definitely not started:
$ ps fax | grep avahi
3959 ? Ss 0:00 avahi-daemon: running [masternotebo.local]
3960 ? Ss 0:00 \_ avahi-daemon: chroot helper
4210 pts/1 S+ 0:00 | \_ grep avahi
Now when I restart avahi-dnsconfd manually right after boot and take a look at the running processed, this is what I get:
$ sudo /etc/rc.d/avahi-dnsconfd restart
:: Stopping Avahi mDNS/DNS-SD DNS Server Configuration Daemon [FAIL]
:: Starting Avahi mDNS/DNS-SD DNS Server Configuration Daemon [DONE]
$ ps fax | grep avahi
3959 ? Ss 0:00 avahi-daemon: running [masternotebo.local]
3960 ? Ss 0:00 \_ avahi-daemon: chroot helper
4535 pts/1 S+ 0:00 \_ grep avahi
4526 ? Ss 0:00 /usr/sbin/avahi-dnsconfd -D
Somebody with avahi-daemon + avahi-dnsconfd please have a look at his machine, because service discover maybe not be an indicator if it's running (I honestly have no clue about the avahi workings, and I also don't know what the second daemon avahi-dnsconfd is for). Because I never got an error on boot, as long as the avahi-dnsconfd entry is after avahi-daemon in the daemons array, I also only found out about the problem, because avahi-dnsconfd failed on shutdown (what I barely do, because this notebook is only suspended most of the time). BTW If both daemons are running, and I suspend-to-ram and return, it is again the same situation as when booting, so avahi-daemon running, and avahi-dnsconfd not. There has to be a problem with avahi-daemon needing more time, before avahi-dnsconfd can connect to it, but that way this problem should be on everybodies Arch machine as well.
Offline
Ok, I think I am a bit further now, after studying /var/log/daemons.log. networkmanager and dhcp seem to have nothing to do with this issue, but the fact, that avahi-daemon kills itself on startup & restarts without root privileges:
avahi-daemon[3959]: New relevant interface eth0.IPv4 for mDNS.
avahi-daemon[3959]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.218.
avahi-daemon[3959]: Registering new address record for 192.168.1.218 on eth0.
avahi-daemon[3959]: Got SIGTERM, quitting.
avahi-daemon[3959]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.218.
avahi-dnsconfd[4526]: read(): EOF
avahi-daemon[5272]: Found user 'avahi' (UID 84) and group 'avahi' (GID 84).
avahi-daemon[5272]: Successfully dropped root privileges.
avahi-daemon[5272]: avahi-daemon 0.6.16 starting up.
avahi-daemon[5272]: Successfully called chroot().
avahi-daemon[5272]: Successfully dropped remaining capabilities.
avahi-daemon[5272]: Loading service file /services/sftp-ssh.service.
avahi-daemon[5272]: Loading service file /services/ssh.service.
avahi-daemon[5272]: socket() failed: Address family not supported by protocol
avahi-daemon[5272]: New relevant interface eth0.IPv4 for mDNS.
avahi-daemon[5272]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.218.
avahi-daemon[5272]: Network interface enumeration completed.
avahi-daemon[5272]: Registering new address record for 192.168.1.218 on eth0.
avahi-daemon[5272]: Registering HINFO record with values 'I686'/'LINUX'.
avahi-daemon[5272]: Server startup complete. Host name is hostname.local. Local service cookie is 2247435772.
avahi-daemon[5272]: Service "Remote Terminal on hostname" (/services/ssh.service) successfully established.
avahi-daemon[5272]: Service "SFTP File Transfer on hostname" (/services/sftp-ssh.service) successfully established.
As I see it, avhi-daemon gets started on boot by the init-script with root privileges sucessfully and reports back [DONE], but then it kills itself, to start with a new PID as user:group avahi:avahi. In the meantime avahi-dnsconfd gets started by the init-script, but can not connect to the selfkilled avahi-daemon-process. That explains, why it can be started without problem manually after boot.
This exact same problem should be present on all machines running Arch, so somebody running avahi please have a look after booting with 'ps fax | grep avahi' and 'cat /var/log/daemons.log | grep avahi'.
The question is now, how to tell avahi-dnsconfd to wait and connect to the second avahi-daemon process?
Offline
Here is my output:
$ ps fax | grep avahi
4509 ? Ss 0:00 avahi-daemon: running [flusenfalle.local]
4510 ? Ss 0:00 \_ avahi-daemon: chroot helper
4534 ? Ss 0:00 /usr/sbin/avahi-dnsconfd -D
5998 pts/2 R+ 0:00 \_ grep avahi
Jan 31 20:50:36 flusenfalle avahi-daemon[4473]: New relevant interface eth0.IPv4 for mDNS.
Jan 31 20:50:36 flusenfalle avahi-daemon[4473]: Registering HINFO record with values 'I686'/'LINUX'.
Jan 31 20:50:36 flusenfalle avahi-daemon[4473]: Registering new address record for 192.168.1.78 on eth0.
Jan 31 20:50:36 flusenfalle avahi-daemon[4473]: Successfully dropped remaining capabilities.
Jan 31 20:50:37 flusenfalle avahi-daemon[4473]: Server startup complete. Host name is flusenfalle.local. Local service cookie is 923499486.
Jan 31 20:50:38 flusenfalle avahi-daemon[4473]: Service "Remote Terminal on flusenfalle" (/services/ssh.service) successfully established.
Jan 31 20:50:38 flusenfalle avahi-daemon[4473]: Service "SFTP File Transfer on flusenfalle" (/services/sftp-ssh.service) successfully established.
Jan 31 20:57:55 flusenfalle avahi-dnsconfd[4502]: Got SIGTERM, quitting.
Jan 31 21:50:36 flusenfalle avahi-daemon[4473]: Found user 'avahi' (UID 84) and group 'avahi' (GID 84).
Jan 31 21:50:36 flusenfalle avahi-daemon[4473]: Successfully called chroot().
Jan 31 21:50:36 flusenfalle avahi-daemon[4473]: Successfully dropped root privileges.
Jan 31 21:50:36 flusenfalle avahi-daemon[4473]: avahi-daemon 0.6.16 starting up.
Jan 31 21:50:36 flusenfalle avahi-dnsconfd[4509]: Successfully connected to Avahi daemon.
want a modular and tweaked KDE for arch? try kdemod
Offline
Damned, your log output shows a completely different startup of avahi-daemon. Is this really what you get on a fresh boot?
I don't really understand, because I did not edit any avahi config files, and for the entries in the daemons array it is only relevant, that network is started in advance, and that avahi-daemon comes before avahi-dnsconfd.
As seen in your log, avahi-dnsconfd first gets SIGTERM, but then connects just fine to avahi-daemon, whereas in my log it only tells "read(): EOF" and doesn't show up a second time. What the hell could be different in your setup???
I don't know how to analyse this problem further, because it's quite a pain to always have to reboot to check if something changed.
Offline
Ok, after a new installation, it is clear now, the network-manager is causing this problem, although I have no clue, what the connection between network-manager / avahi-daemon / avahi-dnsconfd could be. Fact is, without network-manager avahi-dnsconfd is starting as supposed to. I know that avahi-dnsconfd isn't really necessary in a dhcp-managed-network, nevertheless I am curious why this problem occurs with network-manager.
Anybody with network-manager + avahi in use any idea?
Offline
You must start avahi-daemon after dbus daemon ! add it
Here mine:
DAEMONS=(syslog-ng ipw3945d hal !network dhcdbd networkmanager @networkmanager-dispatcher netfs @powernowd @alsa @bluetooth acpid @crond gdm dbus @avahi-daemon @avahi-dnsconfd @samba @vmware @cups)
I hope I help you
Last edited by atlas95 (2007-02-13 09:45:28)
Offline
No, that's not the issue, because already gets started by dhcdbd (look at the init script), so it is already up and running when the avahi-daemon init-script is processed.
It's definitely the networkmanager, because it's working as supposed to without it, but I did not find any solution by now, and I also didn't look further, because avahi-dnsconfd is not needed on a dhcp-managed network (it tells in the installation note, that this daemon is only useful on peer-to-peer networking without dhcp).
Offline