/etc/init.d/avahi-daemon is useless

You have to edit /etc/defaults/avahi-daemon or enabled avahi-daemon from gnome's network settings tool or kde's control panel.

But yes, it would be fine to have some kind of message if it's disabled and one tries to run the init script...

Thanks!
But I must say the init.d scripts should always work. The gnome/kde settings could instead of changing /etc/defaults/avahi-daemon, add or remove a symlink from init.d to rcX.d...
It would mean support for one less file, and people wouldn't have to know about all these /defaults/ directories, it just adds a layer of knowledge one has to have to debug things.
Keep it simple. Thanks for the solution anyway.

The init script is for human use only anyway. avahi-daemon is started by dbus, not by the init script.

Even more reason for the init script to actually _do_ what it is asked no matter what a defaults-file says. If it's only for human use :)
Or maybe I've missed the point here.

See also the comments on bug #55836, which I have marked as a duplicate of this.

My 2c is that this behaviour contradicts the behaviour of all other daemon type packages which are installed.

By default, a daemon is enabled when you install it in Ubuntu, and avahi-daemon now breaks that "rule".

Consistency is a good thing.

yeah, i gotta say this really makes no sense ... you can't even make avahi-daemon run at startup by enabling it in sysvconfig ... thankfully i found this bug report, though.

While it is started by dbus, it links to ../init.d/avahi-daemon so the init script is the one used by dbus

See also Bug #65587

See in Bug #65587

---
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
---

Bah, there are many precedents in Debian and Ubuntu for this behavior. Making /etc/init.d/avahi-daemon ignore the system setting in /etc/default because people are too lazy or stupid to read the initscript is dumb when many other packages work this way, including many in universe (that won't be similarly changed).

What happens when you edit /boot/grub/menu.lst, and don't respect the Debian/Ubuntu way of doing things? It gets clobbered the next time update-grub is run.

What happens when you add a line to /etc/modprobe.conf? You get to keep both pieces. Ubuntu isn't Gentoo, or SysV.

That upgrading to edgy from dapper silently turned off avahi-daemon is a bug, IMHO, but making /etc/init.d/avahi-daemon ignore /etc/default is not a fix for that.

What happens when people "helpfully" add the "missing" SysV runlevel symlink for avahi-daemon, and things stop working correctly? The best answer is "you get to keep both pieces", but only after hard-to-understand bug reports.

Or perhaps it's more "well don't do that then" which equally applies to this. If something really must be done for this "bug", move the avahi-daemon script out of /etc/init.d, so people don't find it and expect it to work a certain way.

"too lazy or stupid to read the initscript"

I was neither too stupid nor too lazy to read it. The point is that I *should not have to*. Luckily enough I was able to figure this out. Ubuntu is supposed to be for everyone and many people wouldn't be able to figure this out.

In case you still disagree with my stance, here's a use case for from the design doc:

---
Sayid is an experienced UNIX user, with multiple years of experience. He does not wish to have to relearn that which he has learned already, and would rather continue using the tools that he is used to and only learn the newer ones when necessary.
---

https://wiki.ubuntu.com/ReplacementInit

Also, I'm not saying initscripts should ignore /etc/default, I'm saying that there should not be a "don't start the daemon" switch in /etc/default. The correct way to not start a daemon is to not invoke its initscript!

As for precedents, a quick poke around in my /etc/init.d turns up no other examples of conditional startup installed at the moment. So I would argue that what you call precedents are bugs too.

I agree with you that the current version does not belong in /etc/init.d but rather than just moving it somewhere else, it should be fixed to work like a standard initscript and if you really want a script with the current behaviour that's fine too, just put it somehwere else.

"Ubuntu is supposed to be for everyone and many people wouldn't be able to figure this out."

If you can't figure this out, you oughtn't be fiddling around with the SysV init scripts. They're not for everyone. Things should "just work", without needing to mess with the initscripts. Once you do, you accept the responsibility to figure it out.

There's a toggle in GNOME: "System->Administration->Networking->General->Automatic service discovery" It makes the change in /etc/default/avahi-daemon. When someone decides to turn on avahi-daemon with a SysV symlink, that toggle will stop working.

(The many packages whose daemons can be disabled via debconf (which usually does the same thing) will have the same problem.)

If there's no way to turn that avahi thing on in $DESKTOP that's a bug. That avahi silently stopped working on upgrade, is a bug (that pref is hard to find!).

This is NOTABUG.

"As for precedents, a quick poke around in my /etc/init.d turns up no other examples of conditional startup installed at the moment."

You almost certainly do. You would have had better luck looking in /etc/default:

apache2
apt-cacher
avahi-dnsconfd
bittorrent
bootlogd (initscripts package)
dbus (and dbus-1)
ddclient
fetchmail
hal
hplip
mdadm
mldonkey-server
nfs-common (toggles for a number of daemons with a single initscript)
portmap
prelink
rscsi (refuses to run if the file in /etc/defaults is missing)
rsync
samba
smartmontools
spamassassin
watchdog

All of those packages (on my system) have the same sort of toggle in /etc/defaults (that affects the init.d script) -- many of them have a file in /etc/defaults for only that purpose.

This is a Debian "standard", just like the alternatives system, update-grub, update-mime, and all their friends.

'This is a Debian "standard",'

It's not a standard or a "standard" it's just something that some packages do and I can't see any benefit to it. The actual Debian standard is here

http://www.debian.org/doc/debian-policy/ch-opersys.html

which is quite clear

"Maintainers should use the abstraction layer provided by the update-rc.d and invoke-rc.d"

and

"These scripts should be named /etc/init.d/package, and they should accept one argument, saying what to do:

start

    start the service,

stop

    stop the service,
"

Please tell me why anyone should have to figure this out. Why can't it just work the way the standard says and the way every other SysV-ish system works.

What is the benefit of this method? Why must the Gnome tool poke values into /etc/default/avahi-daemon? Why can't it call update-rc.d like the standard says it should?

This specific bugs has so many duplicates, that it should become a FAQ! (Frequently Reported Bug)

I've read through all of these posts and can't really find a reason why avahi-daemon would be turned off by default? And moreover, services-admin should be able to turn avahi on.

Right now, services-admin and the init.d script both have no effect on avahi starting so even a CLI user would not know what is going on. Also, my computer tries to start avahi at boot but it fails. Nothing more is outputted.

What are people supposed to do that have no concept about the command line, init scripts or dbus? For a GUI user, there is no way to get this working. There is a bug if you are required to go reading through bash scripts to get avahi working and it should be fixed.

Also, Sebastien is right. There should be something on the FAQ about this to make this information more accessable to users.

The reason is because of Ubuntu's no open ports policy, thus it cannot be enabled by default

There *is* a GUI way

System->Administration->Networking "General" tab click "Enable service discovery"

So, is there something wrong with the fix where we make the initscript a normal initscript (ie it does what it's told) and we just don't link it into /etc/rc.* or the dbus directory. Then the GUI tool can just invoke update-rc.d to turn it on or off, like a good Debian citizen?

Thanks for clearing that up for me. It still leaves pointless controls in the System->Administration->Services dialog, though, as well as the init script that does nothing.

There must be a way to at least consolidate the GUI stuff so it does what it looks like it would do. Maybe have the Services dialog change the /etc/default/avahi-daemon status to "1" as well as start the service?

Luke, you are proposing to add a special case to the Services dialog for avahi. The sevices dialog is a generic piece of code that knows nothing about individual services. To justify such a change one would have to explain why avahi daemon is special and can't just work the way everything else does - and there is no so such explanation.

Another question. Why is avahi started by dbus in the first place?

I'm pretty sure the Serivces dialog just runs the init.d script. I'm not proposing to change the Services dialog at all; Merely change /etc/init.d/avahi-daemon to make "start" and "stop" do just that. Then the Services dialog would function as normal instead of being ignored.

Avahi-daemon *is* a special case in it's current state because it is the only "service" that has a special checkbox in the System->Administration->Networking "General" tab required to make it work. There are many many bug reports about this so, obviously, having a special case for avahi-daemon is too obscure.

The user does not care if it is started by dbus or by a hampster running on a wheel, the user only knows that it doesn't start the way every other service appears to.

Luke, I 100% agree with you, I have already been arguing that avahi daemon should just work like everything else. Your comment seemed to be suggesting that the services dialog should be modified to twiddle the /etc/default/avahi-daemon.

The question about "why dbus?" was for the avahi maintainers - I'm trying to figure out the rationale behind the current setup.

"why dbus?"

because debian doesn't (didn't?) have a way to tell that a service depends on another one , and that when you restart a service, it should restart the services that depends on it.

So avahi is started by dbus like hal.

Since upstart is now ready we don't need anymore to use dbus to start avahi, upstart should take care of this dependency.

@Mr. Daley:

"Luke, you are proposing to add a special case to the Services dialog for avahi"

You are proposing to special-case the avahi-daemon initscript. I won't speculate as to why.
I have demonstrated that this behavior is very common in Debian, and so in Ubuntu, and I don't see that you have responded to that in any way.

This is a long-established way for initscripts in Debian to behave. Making Avahi behave differently because -- well, I don't know -- would be inconsistent, and you have not provided a justification for it that I can see. Rewriting every initscript for Ubuntu to remove this Debian feature is not likely to happen, I think -- especially not for packages in universe.

If you're argument is against disabling a daemon's initscript in /etc/default alone, please propose that this behavior be removed from Debian on the debian-devel mailing list, and let us know who that turns out.

Linking to the Upstart "manifesto" seems disengenious to me. I cannot claim to speak for the authors of that document, but I can't imagine they meant that this established behavior be removed from Debian and it's derivatives.

Joseph.

You seem to have conveniently forgetten the other link I posted, so I'll post it again.

http://www.debian.org/doc/debian-policy/ch-opersys.html

This is the debian policy on how daemons should work. "start" for starting, "stop" for stopping and update-rc.d for enabling and disabling.

By the way, I had a look at your list of packages that do similar things. Most are not installed on my machine so I installed portmap. It's initscript always obeys a start command, there's no if $START_DAEMON. Some others _do_ do what you say. I'm not sure how you came up with that list of packages.

Just because there are other scripts out that don't follow the standard doesn't make it right. In the case of avahi-daemon actually be some justification for it since apparently avahi needs to be started by dbus and dbus is not compatible with /etc/init.d, however this piece of info has only very recently been mentioned. In the case of mdadm or fetchmail, there appears to be no such reason.

It's actually nothing to do with being started by D-BUS

It was simply decided by the developers to do it this way, because editing the RC symlinks was considered "wrong" I guess.

I admit this was a bad way to do it, I was going to implement a patch to check how it was being started but I wasn't able to get it in time for edgy unfortunately.

I've emailed Mark Shuttleworth about the Ubuntu policy aspects of this debate and he contacted Matt Zimmerman about it. Matt replied to me with this:

"These two issues [avahi by default and avahi init not working] are not in fact separate; they have a causal relationship.
The reason why the init script does not work as expected is that avahi is
disabled by default. We intend to change that, and both of your concerns
vanish in one fell swoop."

Developers are working on this issue.

Feisty now enables avahi by default, so the init script works. If you manually disable avahi, the init script is not supposed to do anything, so this should be just fine now.