"/etc/init.d/avahi-daemon start" doesn't start anything

Bug #65587 reported by Fergal Daly on 2006-10-11
This bug report is a duplicate of:  Bug #56426: /etc/init.d/avahi-daemon is useless. Edit Remove
Affects Status Importance Assigned to Milestone
avahi (Ubuntu)

Bug Description

If I install avahi-daemon and then do

/etc/init.d/avahi-daemon start

the daemon should start. Instead I have to change /etc/default/avahi-daemon so that it doesn't set AVAHI_DAEMON_START=0.

This setup doesn't seem to serve any purpose. Is there some scenario in which I would invoke the initscript but want it to do nothing?

I suggest removing this file (or leaving it empty) and also removing


which is just a script to toggle this variable.

Trent Lloyd (lathiat) wrote :

The purpose this serves is that avahi-daemon will now be installed by default, but we do not want it to start by default, this is an option provided by the network preferences.

This is somewhat slightly confusing, but it's been determined the 'best' way to do this

Changed in avahi:
status: Unconfirmed → Rejected
Fergal Daly (fergal) wrote :

I have avahi daemon installed but it's isn't mentioned in /etc/rc?.d and I can't find anything in /etc that wants to invoke it. I presume this is all related to upstart but I don't really know what's going on.

By all means have a script for controlling the daemon however you like but you shouldn't break the long-established semantics of /etc/init.

Is there a thread somewhere that explains why this isn't controlled via /usr/sbin/update-rc.d, like every other daemon?

Trent Lloyd (lathiat) wrote :

Fergal: you can run the script with /etc/init.d/avahi-daemon (dont forgot to also fix the /etc/default/avahi file)

Please note that with the change to upstart in ubuntu I beleive the /etc/rc?.d stuff has changed but I'm not really familiar with the changes there (they are backwards compatible, e.g. you can link stuff into rc?.d, but the default ubuntu stuff is not put there, it is done the native upstart way)

Please refer to the upstart docs as again I'm not familiar how that works.

Fergal Daly (fergal) wrote :

My point is that this is the only initscript in the world which has a "don't forget to tweak the obscure ACTUALLY_DO_WHAT_I_SAY setting" warning to it. Worse still, it doesn't even have the warning _attached_ to it, you have to find out by debugging the initscript.

I doubt I'm the only person who's going to be confused by this. Everyone will assume that making a link to rcX.d will turn avahi on at startup, not having a link will leave it turned off.

Can you explain why that was not acceptable? Why does avahi-daemon need to do it differently?

Trent Lloyd (lathiat) wrote :

Actually it's not the only package, I know among other things bittorrent and rsync have this option, and it's there so that avahi can be installed by default but not enabled on an ubuntu system.

Yes it is a little confusing, that is unfortunate.

As for upstart/rc?.d links, thats the price of moving forward into a better init sytsem, it's simply something people will have to learn like the various other changes I guess

As for a warning, see https://launchpad.net/distros/ubuntu/+source/avahi/+bug/65603

Fergal Daly (fergal) wrote :

Surprisingly there are others too - bootlogd and tomcat for example but that doesn't make it right.

I found the following

fergal@lap /etc/dbus-1/event.d> ls -l
total 8
-rwxr-xr-x 1 root root 1901 2006-09-20 14:15 20hal
lrwxrwxrwx 1 root root 25 2006-09-28 17:52 25avahi-daemon -> ../../init.d/avahi-daemon
-rwxr-xr-x 1 root root 1783 2006-09-08 12:52 70system-tools-backends

and by removing that link I was able to prevent avahi coming up at boot time. So upstart is configured in basically the same way as the rcX.d system.

Again, why is this necessary? With upstart you configure boot-time services with symlinks, just like the old system but in a different place. So why not do that?

Here's another point, any service that behaves like this cannot be run just for the current session. You have to flip the config file, run the initscript and remember to flip the config file back again and tough luck if the service locks your machine up and you didn't get a chance to flip it off before it reboots and locks up again.

This is not progress. If you're being advised that this is now "the right way to do things" I'd be happy to take this up with whoever is saying that.

Fergal Daly (fergal) wrote :

One other thing, in relation to the other bug you mention. Initscripts should _need_ to print things out or test for interactivity. They should just do what they've always done and start/stop services.

If it's correct to add this code to avahi's initscript then it should really be added to every other one too.

Trent Lloyd (lathiat) wrote :

Ah yes I forgot dbus starts it not rc?.d.. oops..

What would you propose is the best solution?

Given dbus starts it.. im thinking perhaps we could move the default start behavior to ONLY affect the dbus script and leave /etc/inti.d/avahi-daemon to work as expected

That would then leave 2 places to check if avahi is being started tho but perhaps that is the better solution

Fergal Daly (fergal) wrote :

I'd argue that

/etc/inti.d/avahi-daemon start

should start it unconditionally and then the toggling on and off should be done with the addition or removal of symlinks. That's how rcX.d works and it looks like that's how dbus works too.

rcX.d comes with a tool for creating a removing the symlinks update-rc.d, if dbus or upstart don't come with equivalent tools then that's a bug. In fact update-rc.d should just work whether the system actually uses rcX.d or something else.

If you want to stick with enable_avahi then I suggest you have it make/remove symlinks instead of sedding /etc/default/avahi-daemon.

If you want to have it turned off by defualt then at install you just don't make the link in the dbus directory.

I think that leaves everyone with things working as they'd expect them but you still have the ability to enable/disable the boot behaviour and leave it off by default.

Russell Cloran (russell) wrote :

I am very very +1 on what Fergal has to say.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers