Date: Mon, 25 Sep 1995 22:23:37 -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: <9509260523.AA29884@asimov.volant.org>
next in thread | raw e-mail | index | archive | help
|> From: patl@asimov.volant.org
|> > 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.
|>
|> That's where we differ. I don't see any advantage to it.
I can. And I don't seem to be alone.
|> > 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.)
|> >
|> > 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.
|>
|> It's a question of how much flexibility is going to be commonly used vs.
|> how much effort it take to implement each increase in flexibility.
Sorry, I don't buy the 'commonly used' argument. I could retire if I
had a dollar for every time I've cursed some anonymous engineer for
building something with gratituous limitations because he refused to
look beyond his own concept of how it was to be used, and thereby
prevented me from using it slightly differently.
I do agree that it is necessary to balance implementation effort against
increase in generality and flexability. But don't try to estimate how
many people will actually use the additional power.
If there's one thing I've learned in twenty three years as a systems
level software engineer, it is that it is impossible to imagine all
of the ligitimate ways that people will want to use your product; and
that you can be considered an engineering god if you just stay out
of their way...
|> But I agree that run-states are worth the effort. It gets us the most
|> for only a medium increase in difficulty.
Wow, a point of agreement! :-)
|> > 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.
|>
|> No it is not the simplest. And that it was done "very well" is entirely
|> debatable. As I said, it comes down to a religious argument.
It is the simplest mechanism that provides equivalent power.
|> I don't like it, you do.
I'll happily abandon it if I'm presented with a better solution. But
loss of functionality simply to reduce the number of i-nodes used doesn't
strike me as better.
|> > |> 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.
|>
|> Each sub-system has it's own script. A control file determines what
|> gets run when. Or each sub-system has it's own script, and directory
|> ordering in a sym-linked tree determines which gets run when.
Right. And it is orders-of-magnititude safer to add a file to a directory
than to automatically insert a line at the right place in a control file.
|> It's not that SysV confuses me, it's that I think it is a LOUSY DESIGN.
|> Personal opinion, which is a matter of a lot of experience. I've been
|> doing unix system and programming admin for about 10 years. And I like
|> the BSD way over the SysV way.
But it isn't 100% lousy. Some parts, like the init scripts, are
the best solution so far.
|> > Don't say "SysV is doing it so we shouldn't"!
|>
|> I'm not saying not to do it because someone else is, I'm saying
|> not to do because I consider it a bad design and most examples
|> of it bad implementations of that bad design.
|>
|> > I really think you are letting your hatred for SystemV color your
|> > judgement here. Sit back and pretend that this mechanism was not
|>
|> I don't reject SysV style ways of doing things because they come
|> from SysV. I reject SysV because it does things those ways.
|>
|> I don't care who invented it. I've looked at it, worked with it,
|> and don't agree with it. It's really that simple.
Hmmmm. That's not the impression you leave from some of your other
arguments.
|> > 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.)
|>
|> Would I still be against it? Yes. I was against it the first half-dozen
|> times I had to work with it (and still am after 10 years), and I was
|> against similar designs I've run into on entirely unrelated projects.
Ok, I'll accept that you have a long-standing dislike for the method.
|> I prefer to keep configuration information explicit, in a file,
|> not implicit, in a sort order.
I just don't see any big difference in explicitness between a control
file and a file naming convention; especially when the filenames have
something as obvious as two digits in the first three positions.
|> I prefer to keep one copy of things, not two - even if they are links.
So do I. But I'm willing to recognize when the extra link is worth it.
In this case, it improves clarity and power. To me, that's a clear win.
Especially since your method duplicates the information about what
is to be done - there is the script, and the entry in the control
file. This leaves open the possibility that one will exist without
the other. (Ok, it's likely to be a pretty obvious problem. But
anyone who might be confused by 'implicit' file sort order is likely
to have problems noticing that they've gotten out of sync.)
|> The two options for ordering determination are the control file ("inittab"
|> or "init.conf" or whatever it's called) and the "rc?.d" directories with
|> sym-links and names based on start/stop and numeric ordering.
I think we want an inittab in either case. The difference is in how many
entries it is expected to have, and whether it is likely to be modified
at each site.
We also want the individual service scripts to be the identical for
both methods.
|> Details on how to best implement each them become unrelated discussions.
|> Except that anything in common becomes part of the underlying foundation,
|> so that only the differences are implemented in parallel.
It would be nice if there were enough cross-discussion that a standard
setup for one method could be automatically generated from the other;
just to make life -much- easier for the folks putting together system
releases. I suspect that it would be easier to generate control files
from the rc?.d setups than the other way around; but that would depend
a lot on exactly what went into the control files.
|> > |> But we'll end up with something that is simply fantastic,
|> >
|> > That's a lot tougher. The biggest problem being to make the package
|> > installation scripts able to handle the necessary updates for both
|>
|> Each mechanism will have to have a means to automatically add config
|> information. These two will become subroutines of some overall tool
|> (called "pkg_init_setup" or whatever).
More complication for people doing ports; but probably not outrageously so.
|> > |> it adds to the end of the file. Or adds to the first (or
|> > |> fourth or ...) line after its dependancy.
|>
|> > If it can find the dependancy. And doesn't mistake something else for it.
|> > Which basicly means it will work fine in the lab and fail miserably in the
|> >real world. I have yet to see an automatic editing system which was robust
|>
|> Anything which can figure out the correct number to use for the script
|> name can figure out where to place itself in a file. If it can't, then
|> it can't and the argument become moot.
Bzzzzttttt. Wrong. The sequence number can be static - built in when
the package was built. It is the same for all systems. The file editing
must be done dynamically at installation time, by examining and modifying
a file that is likely to be different at each site.
|> |> > No. Because the number is not the only designator. By definition,
|> |> > collisions in order designation are "don't care". This is because if
|> |>
|> |> Again, you can always append to the file if it is a "don't care",
|>
|> > It's a matter of how simply the logic can be applied. With the numbered
|> > file technique, it is generally a simple matter to nail down the sparse
|> > sequence points that are likely to be significant (NFS started, etc.)
|>
|> So the numbers also become run levels (being how much we've started
|> running). Great. Back to argument #1. :-)
I suppose you might think of them that way; but you'd probably be in the
minority. They are significant points within the sequence for a given
state. Points that other services are likely to be dependant upon. You
could go with levels instead of states, and make each of these significant
points a separate level. But you don't want that many levels, and you'd
have to re-number if a new one were ever added. (Or identified from
among the services that weren't prereq's for anything else when the
system was first layed out.)
|> > Once that has been done, the install scripts can be written with a priori
|> > knowlege and hard-coded sequence numbers. In the file editing case, the
|> > installation script must be able to recognize the proper insertion point
|>
|> For 99% of cases, just append to the file. You only need to "find the
|> correct point" if you are inserting into the middle of a process chain.
|> Which will probably be a very rare condition, unless you are replacing
|> one startup command with another, in which case the position is
|> already determined for you.
You're thinking in a box again. Do it this way, and I guarantee that
somebody will curse the makers of that decision for getting in the way
of what they need to do.
|> > by examining the file at run time. (And if that doesn't scare you, think
|> > about scripts trying to automatically -remove- services from the script.
|> > If you still aren't scared, you haven't been a sysadmin for long enough.)
|>
|> Granted. Having things remove from a control file requires good
|> solid coding.
Which you trust every maker of a package to do... (And it can still
lose if the lines to be recognized have been hand-editted for any reason.)
|> So does having a script remove a file automatically from the startup
|> directory set, when the name has been permuted with command prefixes
|> (S## or K##).
The S## and K## prefixes aren't really that much of a modification. And
for the more paranoid, check the i-node number on the canonical file in
init.d (which hasn't been renamed), and delete the rc?.d/* files with
the same i-node number. (Yet another advantage of the init.d and hard
links method.)
|> I've worked with both types of systems, and I really have never found
|> one to be more dangerous or less dependable than the other.
I don't know whether to offer congratulations or condolances...
|> If we automate things, we either do it right or we screw up a lot of things.
|> That holds regardless of the automation procedure, or how the underlying
|> layers are implemented.
No, it can work right -almost- all of the time. Which makes it all the
worse when it fails.
|> No. It's which you see as simpler and safer vs. which I see as simpler
|> and safer.
Are you claiming to believe that having an install script edit a file
is safer than having it simply copy a file into a directory?
-Pat
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9509260523.AA29884>