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]