Enabling/disabling/floating services in runlevels
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. I see no problem with that. 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.
> No links in rc?.d means 'take no action when entering that
> runlevel' and is a behaviour some people *want*.
Some people may want it, but in the meantime it remains a fact that
very few packages support their services being configured as "floating"
in a particular runlevel (i.e., lacking both S and K links in the rc?.d
for that runlevel). Therefore, the absence of both S and K links in
some rcR.d does not currently have the desired effect.
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.
> (This discussion has been going in circles for a while, it seems to
> me. Everybody should take a step back, wait 48h and then start again
> in a new thread, perhaps with a summary of what the issues under
> discussions actually are. There's at least 2: (i) how should the rc?.d
> links be handled and (ii) which command should Debian users use to do
> so. But I have not read this discussion thoroughly, so maybe I just
> misunderstand some of you.)
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.)
By "correct way" I mean the way that does not suffer from one the
following deficiency.
If there is neither an S nor a K link for a service in a particular
runlevel and the service's package is upgraded while the system
is in that runlevel then the service will be started even if it was
not running before.
The invoke-rc.d program could be changed so that if a service was
neither S nor K in the current runlevel then start requests would be
rejected. (Invoke-rc.d currently accepts start requests under these
circumstances.) But then such a service would end up getting stopped
on package upgrade even if it was running before. If invoke-rc.d
were further changed so that it didn't stop services under these
circumstances then the result would be that such services would not
be restarted on upgrade.
For the absence of both S and K symlinks to become a valid configuration
for a service, the service's initscript has to implement the try-restart
method and the package has to execute try-restart instead of stop and
then start. Most packages fail to implement the try-restart method and
thus don't support the absence of both S and K symlinks as a valid
configuration.
ii) The rc symlinks should be configured in the correct way.
The rcconf program does not configure symlinks in the correct way.
Neither does webmin.
Several other runlevel editing programs do it the correct way,
including ksysv and Joe Oppegaard's sysv-rc-conf. John Hasler's
sysvconfig will also do the right thing once it is fixed so that
it doesn't wipe out your rcS.d directory. ;)
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.
However, they bloody well should care if they want Debian to live
up to its reputation for technical soundness.
The sysv-rc system was not designed to make it easy to put services
under "manual control". The only way to control a service manually
such that its state won't change on upgrade is to do the following.
Suppose you are in runlevel R and want to start service foo which is
currently disabled in R. First rename /etc/rcR.d/K??foo to
/etc/rcR.d/SXXfoo where XX is a sequence number appropriate for foo.
Second, run "invoke-rc.d foo start". I don't think that too many
people are going to do that. Let's just say that manual control of
interfaces isn't supported yet.
--
Thomas Hood
________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html
Reply to: