Mike Meyer <[EMAIL PROTECTED]> writes:
> > By all means, use start/stop args, but hard link the .sh files into seperate
> > directories or something so that the order can be tweaked..
> If all you want is to make sure that shutdown happens in the reverse
> order of startup, that can be done by reversing the list in
> rc.shutdown. But how about going a step further, and starting towards
> a user-friendly configuration process?
> Instead of being globbed at init time, etc/rc.d is a repository for
> things that take start/stop arguments. They are symlinked to
> /etc/init.d with numeric prefixes to control order at initialization
> time. Likewise, they can be symlinked to /etc/down.d (or shutdown.d)
> with numeric prefixes to control order at shutdown time.
> Note that the directories full of symlinks are in /etc, not in
> /usr/X11R6/etc, etc. The rc.d's in those are also treated as
> repositories, so you can symlink to files in those asd well. These
> should save a bit of time at boot; no need to fool with lists of
> directories, etc. - just one directory.
> The real work will be adding a one-line description near the start of
> the file:
> # Init: 300. Shutdown: -1. Description: Standard smtp (mail) daemon.
> (indicating that it should be installed as /etc/init.d/300sendmail.sh,
> and no shutdown installation is necessary).
I guess you would like to says that scripts.sh lives in /etc/init.d
while XXXscripts.sh lives in /etc/rc.d and /etc/shutdown.d. if not,
you are at the oposite of the SystemV semantic ! and would be a pain
for system administrators. why not to simply adopt the SystemV semantic ?
not all is bad in System V :)
> Later, we can add a tool that globs the etc/rc.d directories for files
> with those lines, and provides a nice visual "system process
> configuration" tool, allowing you to click on these things to move
> them back and forth. Some rules regarding the shutdown/startup
> priorites might be needed for ports. Given some prodding, I might even
> be talked into taking a crack at the tool (an X tool, maybe) before
> there's a commitment to supporting this structure.
home:mailto:[EMAIL PROTECTED] Supprimer "%no-spam" pour me repondre.
work:mailto:[EMAIL PROTECTED] Remove "%no-spam" to answer me back.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message