Date: Mon, 25 Sep 1995 17:52:42 -0400 From: Coranth Gryphon <gryphon@healer.com> To: gryphon@healer.com, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com Cc: hackers@FreeBSD.ORG Subject: Re: ports startup scripts Message-ID: <199509252152.RAA13441@healer.com>
next in thread | raw e-mail | index | archive | help
From: patl@asimov.volant.org
> And hard links are even more useful than symlinks. With hard links,
> you can easily determine how many states are using a given script
> simply by checking the number of links to the master copy.
...
> Right. One directory per state, and one directory for the cannonical
> location of the scripts.
Same problem. I've just seen two many times when keeping multiple
copies of something has led to problems.
|> Yep. That works. The only problem is shutting things down, if you
|> are not simple shutting everything down.
> |> Actually, at that point you'd need a matrix of what to stop and start
> |> depending upon what run-state you are going from and to.
> |>
> |> All the more reason to go with linear run-levels.
> Not really - a stateX-to-stateY transition could be done by shutting
> down stateX completely and then starting stateY from scratch.
Yeah, thought of that. Was trying to avoid it to maintain continuity
between daemons.
> My problem with run levels is that if I want a state which does not
> correspond to any of the standard levels, it will probably need to
> go inbetween two of the standard ones. (E.g. multi-user, with full
Same problem occurs with states - you have to pick the one closest
to what you want and
> as levels, I'd have to re-number the levels to insert my new state.
Granted, that is a problem. We could solve most of it by allocating
a half-way state that is unused at each point a "local".
> If the implementation supports states, it is easy to provide levels.
> If it only supports levels, using it to get distinct states is going
> to be pretty tough.
Yep, you're right. That's the biggest drawback of levels.
It quickly becomes a matter of - how much flexibility is really going
to be used how often. If it's twice the work for twice the functionality,
it's worth it. If it's twice the work to make +5% people happy, then
it's questionable. If twice the work makes ten people happy, then it's not.
> |> Yep. Alternately, the "cron" script can take an argument of "multi-user"
> |> or "network" and do the right thing.
> Cron shouldn't need to know. And doing that limits the possible cron
> actions choosable from the different states.
Cron doesn't know. The script that runs starts/runs/creates/whatever
the crontab entry knows.
|> in summary, my druthers are:
|> > one directory for all start and stop scripts
|> > explicit invocation order, a list
|> > one name per script regardless of run-state/level
|> > (no links hard or soft)
|>
> One master directory for start/stop/restart scripts.
> One directory per run state, with hardlinks to above.
> Invocation order dictated by digits in script name.
As I said in my response to Terry, it quickly becomes religious
discussion of which is better, numbered scripts or control files.
> --- NO SCRIPT EDITING !!! ----
We are not talking about script editing. We are talking about adding
a line to a control file, versus adding a line to a directory.
> I cannot possibly overemphasize the advantages of a system which
> avoids the need to ever automatically edit any file. This avoidance
> is the single biggest advantage of the SVr4 model.
And one of it's single biggest confusions. I prefer BSD variants
over SysV variants BECAUSE of design decisions like this.
A lot of other people probably do as well.
If you want SysV, use Linux. If you want FreeBSD to get some new
flexibility (based upon concepts from anywhere else) - GREAT.
But don't say "SysV is doing it so we should"!
At this point, we have two distinct camps - those who want to see
the {S|K}NNfoo scripts in "rc?.d" with a copy in "init.d" subdir.
In other words "SysV".
And those of us who want one directory ("init.d") and a control
file to specify what gets run when. In other words, a hybrid.
Neither camp is going to convince the other. So someone who can make
the decision of which direction to head in should do so, and let
us get down to doing the best implementation of whichever that we can,
rather than debating it for another three months, and then kludging
something together in a hurry.
Or, if we want to put a little more work in, we can do both and
make everyone happy. We have to define the commonalities (one
script per subsys/package/component, a copy in "init.d") and a
fixed interface so that the two different startup "descriptions"
can both use the underlying mechanism. What this means is that
both camps will write versions, and make sure they work together.
But we'll end up with something that is simply fantastic,
and will suit both styles.
If we go with control files, or with the do-it-both-ways system,
count me in as willing to do a large chunk of it.
-coranth
------------------------------------------+------------------------+
Coranth Gryphon <gryphon@healer.com> | "Faith Manages." |
| - Satai Delenn |
Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+
USMail: 3 Hansom Drive, Merrimack, NH 03054
Disclaimer: All these words are yours, except Europa...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509252152.RAA13441>