New ZeroConf Spec

Matthew Palmer mpalmer at hezmatt.org
Tue Jul 4 23:43:02 BST 2006


On Tue, Jul 04, 2006 at 02:48:22PM +0800, Trent Lloyd wrote:
> On Tue, Jul 04, 2006 at 04:03:05PM +1000, Matthew Palmer wrote:
> > On Tue, Jul 04, 2006 at 11:35:59AM +0800, Trent Lloyd wrote:
> > > I also feel that removing avahi in synaptic is not the way to go about
> > > disabling avahi, that can be done simply by stopping and preventing the
> > > daemon from starting on boot with the /etc/default infrastructure that
> > > is now in debian.
> > 
> > Using /etc/default is Just Plain Wrong, because it prevents you from
> > starting the service at any other time, too.  The *correct* way to stop a
> > service from starting at boot is to modify the symlinks in /etc/rcN.d. 
> > sysv-rc-conf is available (amongst other tools) to manipulate the symlinks
> > on your behalf if you're not comfortable doing it by hand.  update-rc.d is
> > not recommended, due to being a mighty poor UI for the command line.
> 
> This is true and has often annoyed me, however, can sysv-rc-conf restore
> the links back to their original levels?

When you say "level", I presume you're talking about ordering -- so 'level'
within a runlevel, as opposed to which runlevels the service starts in.

It's not *quite* optimal in it's handling of ordering -- when you switch a
service from S to K, or vice-versa, it leaves the ordering number the same,
so, for example (an example I just tried on my laptop), S91apache becomes
K91apache when I uncheck the box in sysv-rc-conf, and then K91apache becomes
S91apache when I check it again.

The correct behaviour, of course, is to make the ordering inverse, so the
ordering number should be 100-<current> when switching -- so S91apache
becomes K09apache.  It's not a massive problem, though, when your primary
purpose is "don't start at boot", and not "make sure everything works right
when I transition between runlevels", because runlevel transition (apart
from S->N and N->[06]) rarely happens on modern systems.

> I noticed update-rc.d didnt' seem to have any idea what they were to
> start to (run order etc)

Yep, update-rc.d doesn't have any knowledge of that, nor is it intended to
-- it's sole purpose in life is to run in a maintainer script and set the
maintainer's idea of default run levels.  Do one job and do it well, and all
that.

- Matt

-- 
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.



More information about the ubuntu-devel mailing list