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 <[EMAIL PROTECTED]> > 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
