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

Re: Enabling/disabling/floating services in runlevels

Le jeu 08/04/2004 à 20:43, J.D. Hood a écrit :
> Adrian 'Dagurashibanipal' von Bidder <avbidder@fortytwo.ch> wrote:
> > On Tuesday 06 April 2004 14.39, John Hasler wrote:
> > [...]
> > > Removing all the links results in them all being reinstalled when the
> > > package is upgraded.
> >
> > which imho is exactly the thing that needs to be fixed in the first 
> > place.
> The absence of links in rc?.d is interpreted by update-rc.d as the
> unconfigured state.

Which is wrong, as it _is_ configured.

Thanks, for making a short summary of the problem :).

>From sean finney, we have : 
> it's possible to know in the postinst whether you are performing a fresh
> install or an upgrade, which is a much more accurate way of determining
> what to do with symlinks in /etc/rc?.d.  

What are the implications of this? ie: Could we easily change the
behviour during an upgrade?
For example in postinst:
 - if we're upgrading, don't touch /etc/rc?.d files
 - if not use update-rc.d as usual
As a sidenote, in this case do we still need the link test in
update-rc.d (install after non-purged remove)?

Back with Thomas Hood :)


>  Even if you want
> to leave a service floating in runlevels 2 through 5 you can still
> put K symlinks in runlevels 0 and 6; that will prevent update-rc.d
> from resetting the symlinks to their default state.

I agree with Adrian von Bidder on the fact that we're going in circle

> If a service is configured as floating in runlevel R and the package is
> upgraded while the system is running in R then the service will be
> started whether or not it was running before.

> This problem is in addition to the one mentioned by John Hasler.


A good way to solve this would be to implement invoke-rc.d status.
But let's keep this one for later :).

> i) In the sysv-rc system we have today, the correct way to control
>    a service is to set up for it either an S or a K symlink in each
>    of the runlevel directories rc2.d through rc5.d , plus K symlinks
>    in rc0.d and rc6.d.  (I am excluding from consideration those
>    initscripts that get run from /etc/rcS.d/.  They are different.)

Agreed, except that to disable a service you can also remove _all_
references to this service in /etc/rc?.d/.
This means "disabled". Don't start it. Don't stop it. Never.
This is widly used; be it by using a find/rm or utils like chkconfig
--del xxx on irix, RH or some other distribs or others.

As an _example_, I use sshd with xinetd. There is no reason to have
a single [SK]??ssh in /etc/rc?.d.

Note that with update-rc.d, if I don't want to have my config messed up
during an upgrade, I need to create a _single_ /etc/rcX.d/K??service
somewhere. Which isn't good either according to what you say.

> I can already hear people saying "But waaah, I still want to delete
> the S and K symlinks and have this disable the service."  Some of
> those will be people who don't read.  Others will be people who
> don't care about Debian packages doing the right thing on upgrade.

They _don't_ do the right thing:

On upgrade they destroy my configuration! Can you understand that?
This is written here on the Debian Policy:
First point: Don't mess with config files on upgrade.

update-rc.d break my config because it doesn't know what to do,
because it's _guessing_ wrong. Hey boy, this is an upgrade, don't
touch my /etc/ files unless You Know What You Are Doing!

OK, I'm going to take my pills :).


Reply to: