On Sat, 2004-01-31 at 22:10, I wrote:
> Note that the expectation of the System V init system is
> that every service have either an S or a K symlink in each
> runlevel. If there is no symlink for a service in a particular
> runlevel then the behavior of sysv's invoke-rc.d is undefined
> for that service in that runlevel. Methods of shutting off
> services must take that into account.
This is true.
> Suppose you have service foo that is S20 in runlevel 2 and
> you want to shut it off. You should do something like:
>
> /etc/rc2.d/$ mv S20foo K80foo_originallyS20
No.
Further investigation has revealed to me that this won't work.
The renamed symlink has to be K??foo or it won't be recognized
as a foo script even though it links to foo.
I conclude that the only correct way to disable a service is
to do something like:
/etc/rc2.d$ mv S20foo K80foo
It is up to the administrator to keep a record of what the
original symlink was called so that he can restore it to that
name later if he wishes to do so.
There are a couple of high-level utilities available that can
automate this process for the administrator.
"Miquel van Smoorenburg" <miquels () cistron ! nl> wrote in part:
> A thought just hit me.
> What if we added a "update-rc.d <name> enable|disable" command?
This has already been wished for. See sysv-rc wish #214757 and
sysvinit wish #67095.
> That has never been done because the implementation would
> be awkward and wouldn't fit into the sysv-rc design.
> But what if we used the destination of the symlink ?
Suppose you have a service foo enabled in runlevel 2 and disabled
in runlevel 3. On moving from 2 to 3 you want foo to be stopped.
However, if foo is disabled in runlevel 3 by having its S entry
symlinked to /bin/true then it won't be stopped.
The right thing to do is to write a simple runlevel editing tool
and include it in the sysv-rc package. This tool would rename
Snn symlinks to K(100-nn) symlinks and vice versa and would keep
records of what it had done so that reversion was easy. The sysv
update-rc.d program would be rewritten to work through the runlevel
editing tool; commands coming from update-rc.d would determine what
the tool considered to be the "default" setting.
Other init systems would implement this tool differently, of course.
--
Thomas Hood <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
