Re: [Fwd: Re: Please remove rcconf]
On Mon, 08 Mar 2004, Thomas Hood wrote:
> Hi. The question of how to switch services on an off in the
> System V init system has come up again, this time on debian-qa.
> I could use some support. // Thomas
>
> -----Forwarded Message-----
> From: Michael Stone <mstone@debian.org>
> To: debian-qa@lists.debian.org
> Subject: Re: Please remove rcconf
> Date: Sun, 07 Mar 2004 16:55:53 -0500
>
> On Sun, Mar 07, 2004 at 10:14:11PM +0100, Thomas Hood wrote:
> >Argh! You're not supposed to delete _any_ links -- just rename
> >them from Sn to K(100-n) and back.
>
> No, deleting them would be fine.
Not really. First, no symlinks at all is taken by invoke-rc.d to mean that
someone forgot to call update-rc.d to register the service, and it won't
like that. We all know how wise is to have no symlinks at all during an
update, so I won't go about why it was implemented that way.
See below for other issues.
> >If there is neither an S nor a K symlink for a service in a
> >runlevel it does not mean that the service should not run in
> >that runlevel.
> >
> >Actually it doesn't mean _anything_. It is a misconfiguration.
>
> no, it's a no-op.
no-op? No. No-op means the init system would always leave that service
well enough alone, even during package upgrades/install/removals.
AFAIK *NOTHING* defines that for sysv-rc, no link means a no-op. So, what
it really means is "I don't care". And this is *NOT* the same as defining
it to be "no-op".
AFAIK, rc will leave the service alone, but don't expect the init system to
know what to do if anyone asks it to decide if that service should be active
or not. And invoke-rc.d will ask just that question if you do a package
update/removal/install. It has to.
What the initscript system decides to do in that case may not be something
you would expect from a "no-op". In fact, currently invoke-rc.d will refuse
to start/restart the service, but it will allow any other action (including
a stop).
I do *NOT* think it is wise to change that. During an upgrade, this would
result in old binaries left running for daemons, that a futher stop may
NOT kill (--exec in start-stop-daemon...), or operating in an undesired
environment (daemon from older package, other files in filesystem for a new
version, which might be incompatible).
I would oppose changing this, due to the reasons exposed above.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: