Date: Sat, 23 Sep 1995 08:53:07 -0700 From: patl@asimov.volant.org To: hackers@freebsd.org, peter@taronga.com, gryphon@healer.com Subject: Re: ports startup scripts Message-ID: <9509231553.AA25492@asimov.volant.org>
next in thread | raw e-mail | index | archive | help
|> From: peter@taronga.com (Peter da Silva)
|> > +> But keeping a set of directories for the sole purpose of linking
|> > +> to one common directory is hellishly redundant.
|>
|> ...
|>
|> > And no, it's not "hellishly redundant". It's actually very convenient.
|> > Much more so than referencing via a file:
|>
|> What I mean was "redundant" is having one directory being a mirror
|> of the other. I honestly can't see what is gained. Either you just
|> put everything in specific directory you want it to be in, or put
|> it in one common directory. Not both.
It isn't a mirror, it's a subset. And it is very convienient to have
easy access to both the complete set and the individual subsets.
|> > + Adding or deleting a script can be done without editing a file.
|>
|> If you want things to be in one directory, and not have a config file,
|> then name the startup scripts based on level. Thus:
|>
|> NNfoo.#
|>
|> Where NN is done for ordering, and # is the run level associated with it.
First, this makes it a bit more awkward for manually restarting, or
for handling services that are -only- started manually. Particularly,
the script name must change if you change a service from manual to
automatic start, or vice versa. For example, with the SVr4/Solaris
scheme I can restart the HTTP daemon via '/etc/init.d/httpd restart'.
I don't need to remember (or look up) which run level it is in or what
its sequence number is. (Which also makes it convienient for scripts
to start/stop/restart services outside the init sequence.)
Second, you are still thinking of the levels as a monotonic sequence
instead of as states. The state concept adds significant power and
flexability at almost no cost. (Pat's design rule #1: Don't get in
your users' way. Just because you don't have any use for arbitrary
states doesn't mean that nobody else does.)
|> > +> Original issue: What do we allow ports and packages to modify?
|>
|> > Answer: We let them put a file in a directory.
|>
|> Yep, sounds good to me. The only problem here is making sure the NN
|> (for ordering) is handled correctly.
That's not that hard. You set a few widely separated sequence points
in each directory, and it generally won't matter what order things
happen between them. And since the links are of the form '[SK]##service',
it doesn't matter if two services happen to choose the same number.
Each of the rc?.d directories should contain a README that lists these
sequence points. (And reminds the reader that the S* and K* files are
links into init.d.)
|> > +> This is the "how much of /etc/rc" do I implement.
|> > +> On going up, run anything <= level with argument "start".
|> > +> On going down, run anything > level with argument "stop".
|>
|> > You may need separate start and stop entries because the order of execution
|> > may be important and not always obvious. Putting start and stop in the same
|> > directory is nice, but make sure you run the stops in reverse order at least.
|>
|> No. I was saying one script per service, that accept (and do the right
|> thing) based upon a single command line argument ("start", "stop",
|> "restart"). Yes, then going up run them from lowest to highest order
|> number, when going down from highest to lowest. This should be relatively
|> simple to implement.
But not necessarily the right order. This is another reason for the
links - you have separate S and K links for start and kill operations.
This also makes it easy to see what is happening for any runstate - just
look in the rc?.d directory - the K* files tell you what services are
being killed (and in what order), the S* files tell you which ones are
being started.
|> To decide upon an init procedure, we need to make two decisons before
|> anything else. First, do we want run-levels or run-states? Second, do
|> we want a control file, or just scripts in a directory?
|>
|> The only thing I have a real strong opinion on is that run-levels are
|> a lot cleaner and simpler (and just as useful in most cases).
I vote for states, an inittab, and a per-state script that automatically
runs other scripts in the directory. (So that package installs -NEVER-
have to edit a script.)
|> That and don't implement both one directory per level AND one common
|> directory. Pick one or the other.
You've completely missed the point of the init.d-plus-rc?.d scheme.
I suspect that no amount of argument or explanation will make it clear.
But I do know that I find it -very- useful.
Init.d tells you all of the services available, and is a very convienient
place to find the service control scripts under fixed names (e.g. httpd)
for invocation outside the system-state-change sequence.
Rc?.d tells you which services will be started or stopped, and in what
order, for a particular run state.
This is not additional complication, it is additional clarity. It
makes life easier for both the experienced full-time FreeBSD sysadmin
and the inexperienced, occasional, or multi-OS sysadmin.
-Pat
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9509231553.AA25492>