Date: Tue, 26 Sep 1995 02:31:31 -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: <199509260631.CAA15855@healer.com>
next in thread | raw e-mail | index | archive | help
From: patl@asimov.volant.org
> Coranth wrote:
> |> 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
More than granted :-)
> |> 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! :-)
I am willing to back down on things that are concrete points. Points
made, points granted :-)
The "my way is better/prettier/swoopier than yours" is an different
type of argument (preference). And one I don't see either side winning.
> [SysV method] is the simplest mechanism that provides equivalent power.
I can't see any more power from a directory listing proving control
order vs. a control file providing that order.
They both have their plusses and minuses.
> 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
OK. Now we can actually cover some coherent points, that do not
relate to personal preference in style.
I say they have equivalent functionality. The only counter argument made so
far is Terry's which talks about Union-FileSystem mounting to overlay files
into the /etc/rc?.d directories (which makes me shudder at the thought).
What functionality does the "rc?.d" sym-linked subdirs method gain over
the control file model?
> |> 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.
Ok. Something that appears to have been lost in one of my mail messages.
I am not talking about the package install script editing the file
itself. I am talking about it calling a command utility (written
as part of the setup mechanism) which will do the editing.
That reduces the risk by an order of magnitude, since the util knows
about the format, and know what is and is not safe to do. All it
needs to be told are dependances to take into account.
> |> 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.
> That's not the impression you leave from some of your other arguments.
Then I'm sorry for not being clearer earlier. Everything in my life is build
around a few simple concepts. First, that there are always more than one way
to do something. Second, that just because you don't like one part of
something, don't let that affect your views on other parts. Corrallary,
if you like something, be careful about assuming you'll like all of it.
Third, if it works, then it is right. Corallary, if it doesn't work,
it's wrong, replace it. Finally, re-evaluate everything constantly,
you might have missed something the first few times.
At every point in this debate, I have re-examined the usefulness and
aesthetics of what you (and others) have presented, as objectively
as I can. Sometimes I came to different conclusions than in the past,
but only if new information was added to the evaluation.
> 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.
It's a matter of personal preference.
|> 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.
That's the style difference. Subdir listing vs control files.
I'm willing to be convinced. What does one gain over the other?
> Especially since your method duplicates the information about what
> is to be done - there is the script, and the entry in the control file.
Granted. But I actually consider that a feature.
The control file tell what has to be done, the scripts do it.
> This leaves open the possibility that one will exist without
> the other. (Ok, it's likely to be a pretty obvious problem. But
Same problem in either version. If it is not in the control file
(or the rc?.d subdir), it doesn't get run. If it is not an existing
script, you get an error on startup.
> 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.
OK. But doesn't the "inittab" and "rc?.d" provide the same redundant
information that you diskliked in the control file method?
What does the "inittab" your proposing gain over just the "rc?.d"
directories with numbers dictating script order?
> We also want the individual service scripts to be the identical for
> both methods.
Definately.
|> 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;
Definately. Two ways to do it. Either both are generated from a common
database, or we have a translation tool that converts from one to the other.
> 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
Yep. Going from subdirs to control file is easy, going the other way is
harder since I do not keep track of explicit number, just relative order.
> |> 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.
Actually, I see it as simpler :-)
With this common tool, all they have to do is execute the utility and give
it the relevant dependancy info (if any). It knows about everything else.
Thus the packages and ports only need to know how to call it, and we
can implement any later install/startup mechanism and only need to change
this one utility.
> |> 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.
> 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.
Urk. OK, I misunderstood where the numbers are coming from. I assumed
that the package would determine the numbers at the local system.
That adds a lot to the shoulder of the ports/packages coordinator,
but does solve all the problems with numbering sequences.
Ok. We have another basic question here: I am hanging onto less information
than you are, in that I am only keeping track of relative ordering, while
you are keeping track of specific numbers. I can't see anything I'm loosing
in not having the explicit numbers, aside from ease of translation back to
your system. Am I missing something?
|> 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
That's what I consider run-levels: plateaus where a certain amount
if system functionality is enabled.
Anything else is what sets of additional things (mounted filesystems,
daemons, subsystems) are run after that point. But the discrete points
I don't think are likely to change.
And we should agree on what goes into each, so that we remain compatible
between the two implementations.
> 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
No :-) You've got me convinced to go with run-states instead of levels,
so I'll stay clear of this train...
> |> 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
Ok. I don't see how. Either it depends upon nothing (thus no problem),
depends upon something with nothing depending upon it (again, simple),
replaces something directly (still simple), or goes into the middle
of a dependency chain. (which case requires most of the design sweat)
I can't see any other case in an ordered system.
|> 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
That's what the command util is for. All the package maker does is
call that tool.
> lose if the lines to be recognized have been hand-editted for any reason.)
Granted. But a person with an editor will always be able to screw up
an working configuration. What we have to do is make it such that
they have no reason to hand-edit any files.
|> 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.
Granted. The dangers come in two places - ports/packages that do not
follow the setup requirements, and sysadmins editing things by hand.
Or very complex packages, that require lots of system modifications
to work. And finding ways to do that automatically. But those other
modifications don't change regardless of which startup method we use.
The question is: is there any fool-proof method, anywhere?
Or do we just do the best we can, design to eliminate as many
problems as we can forsee, and fix the others when they come up?
-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?199509260631.CAA15855>