Date: Mon, 25 Sep 1995 19:32:44 -0700 From: patl@asimov.volant.org To: gryphon@healer.com, jmb@kryten.atinc.com, peter@taronga.com Cc: hackers@FreeBSD.ORG Subject: Re: ports startup scripts Message-ID: <9509260232.AA29636@asimov.volant.org>
next in thread | raw e-mail | index | archive | help
|> > 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.
They aren't multiple copies, they are multiple links to a single copy.
I generally agree that having multiple copies or multiple locations
can lead to problems; but in this case I believe that the advantages
far outweigh the possible difficulties.
|> > 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
No, I can easily create my own state using the next available state
number. Since there's no implied level-ordering of the states, which
number I choose is purely arbitrary.
|> > 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".
Gack. First, one 'local' isn't enough. Second, the new states may
not actually fit between any of the existing states. (E.g., another
contractor I know wants a single-user-with-networking state.)
|> > 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.
But it isn't twice the work. It's barely any more work at all.
|> > |> 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.
Ok, the script invoking the per-service scripts shouldn't need to know
that cron takes a different parameter than other scripts, and a parameter
based on the state being entered.
The SVr4/Solaris2/etc. technique is the simplest and most powerful
mechanism proposed to date. Let's not let a hatred for SysV keep
us from adopting one of the things they did -very- well.
|> |> 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.
How does 'adding a line' differ from 'editing' ? Control file -vs-
script is a minor point compared to the fact of installation scripts
editing shared system control files.
|> > 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 this really confuses you that much, perhaps you aren't well suited
to systems administration. Personally, I'd far rather have the tiny
bit of potential confusion than the huge potential for damage.
|> 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"!
Don't say "SysV is doing it so we shouldn't"!
I really think you are letting your hatred for SystemV color your
judgement here. Sit back and pretend that this mechanism was not
invented by SysV. Pretend that we are inventing it here for the
first time. Would you really be so adamantly against it? (You
don't have to answer publicly - just think about it for yourself.)
|> 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".
Would it help if we struck out "SysV" and substituted "Solaris2", or
do you hate that as well?
|> 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.
Sounds like less of an improvement over the current system than
Windows95 was over Windows 3.1.
|> 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.
Easily done. 'Inittab' and init.d become the 'required' part of the
system, with a control file or rc?.d subdirs and rc? scripts as the
'optional' parts.
|> But we'll end up with something that is simply fantastic,
|> and will suit both styles.
That's a lot tougher. The biggest problem being to make the package
installation scripts able to handle the necessary updates for both
techniques. (And without turning that into another maintainance
nightmare or Rube Goldberg system.)
|> 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.
And if we go with states, rc?.d subdirs, etc., I'll certainly contribute
whatever I can.
-Pat
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9509260232.AA29636>