[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to disable services at startup... and keep them so.

Camaleón wrote:
> In fact, what this thread has shown us is that there is not a standard 
> method (let's call it "a common way") for doing a simple task like is 
> disabling a script from running and keep its current status.
> I was looking for a "Debian way" for handling this, not just with Network 
> Manager but with all the scripts.
> True is that "man update-rc.d" suggests using tools like "sysv-rc-conf" 
> but this tool is no even installed by default, so, how does one can give 
> credit to such tools if they are not part of the base system? >:-)

One of the problems is that traditional Unix systems aren't completely
unified on this topic.  So those that came later have all had to
figure out how to do this on their own.  And as you can imagine
different followers have done it differently.

SGI's Irix started using a process they created called 'chkconfig' to
enable and disable boot time daemons.  Red Hat picked up that process
for their system and so now RH and their derivatives still use
chkconfig to manage the boot time symlinks.  The chkconfig tool
conceptually does the same thing that update-rc.d does but uses a
completely different interface and for completely different reasons.

But fundamentally the Red Hat philosophy requires something like
chkconfig while Debian's philosophy does not.  Let me partially
explain.  Let's look at an example.

In Red Hat by default you will have both Postfix and Sendmail
installed.  Both are mail transport agents.  Each would interfere with
the other and only one can be allowed to run at a time.  RH has
chkconfig to enable the local admin to select which one starts while
allowing both to be installed at the same time.

Debian does this in a completely different way.  In Debian you would
not have *both* Postfix and Sendmail installed.  Instead you will have
*either* Postfix or Exim installed.  They conflict.  You won't have
both installed and won't have to configure the boot time to choose
between them.  Only one will be installed at a time.  Because of this
Debian doesn't need to have a chkconfig script to select between
services.  Debian needs an update-rc.d script to install and remove
services and to be smart about allowing local administrator changes.

Because of the direction taken in Debian the whole symlink process can
for the most part be ignored entirely.  Most users of Debian are
completely unaware of the details of how it is implemented.  Therefore
there hasn't been a big need to make the process more human friendly.
It isn't a big enough problem to warrant significant effort.  This is
really the real reason that it hasn't been made nicer in Debian.  It
just isn't needed.

Meanwhile, on other systems, the issue remains.  Therefore it remains
on the minds of people who use those systems.  When those same people
switch back and forth between those and Debian they are used to
thinking about things in that way and so continue to do to.

Meanwhile, the parallel boot effort has been ongoing and is completely
changing the way the boot time scripts work.  I haven't spent any time
learning how it works.  I expect I will need to at some point.  (Dear
Lazyweb, what is the best reference?)  Because I expect that at some
point everything I know about how the symlink system works at boot
time will be obsolete and gone from the system.  Then it won't matter
that Red Hat and Debian have in the past done things differently.
Both will be doing it differently under the new parallel boot system.

Erm...  Maybe that was four cents.  :-)


Attachment: signature.asc
Description: Digital signature

Reply to: