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.
Great!
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.
Agreed.
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:
http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3
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 :).
Regards,
Patrice.
Reply to: