On Mon, 24 Apr 2000, Bill Sommerfeld wrote:

> IMHO, if you want to be able to dynamically enable/disable subsystems
> based on dependancies, you need to keep track of which ones are
> currently running.
>
> I think this would be best done using a different model for starting
> daemons/subsystems, more akin to an inetd/init model (where a
> management daemon remains as a parent to the managed services) as
> opposed to an rc "fire and forget" model.

  I actually started designing a completely different type of rc utility
that (IMO) has an very good way of doing this.  The basic idea of the
design is that there are really not that many things that such systems
need to be able to do and that most of them are at a lower level then you
get in a shell script.  It uses a separate rc utility with a single, easy
to parse, text configuration file that is unordered at the top level (but
ordered inside each "job").  This utility also communicates with init for
programs that will outlive the startup utility and want to be restarted or
log various things (out or err, when they were started, when and how they
stopped, etc.) or have init write the pid file or clean it up when the
program exits.  Much of the needed functionality is in init already to
deal with ttys (and, in fact, this would allow the parsing of /etc/ttys to
be moved out of init).  It would also be possible to parallelize startup
sanely (since output can be tagged with the command name each line),
though there is still some complexity to DTRT when user input is needed.

  The benefits of this scheme are:
1) init stays close to the size it is today
2) one location for configuration
3) configuration *can* be changed mechanically (you could even have a
graphical version.  While I probably wouldn't use it, the fact that it is
*possible* is IMO a very good thing)
4) you can still start and stop individual programs
5) the program that mechanically edits or verifies the configuration can be
kept dynamically linked in /usr since it is not needed for startup
6) it should actually be reasonably fast

  #6 is the main reason I started looking at this.  rc.d takes >50% of the
startup time on two of my machines (an old laptop and a hpcmips machine).

  Unfortunately, I don't have enough time to get anything near working
code done by 1.5 (and am not going to try since there are other things I
would rather work on now), but I hope to have an implementation done early
enough to be considered for 1.6/2.0.

  I think that something like this is the best way to do rc.  The only
possible disadvantages over rc.d I could think of is that it is Yet
Another Configuration Format and is more different from what other systems
use.  However, I think that this is better then long shell functions and
magical comments (IMO, comments that are anything other then commentary
are a good indicator that you are using the wrong tool for the job).

Matthew Orgass
darkstar@pgh.net