Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Sep 1995 00:02:23 -0700 (PDT)
From:      Julian Elischer <julian@ref.tfs.com>
To:        gryphon@healer.com (Coranth Gryphon)
Cc:        gryphon@healer.com, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com, hackers@FreeBSD.ORG
Subject:   Re: ports startup scripts
Message-ID:  <199509260702.AAA09174@ref.tfs.com>
In-Reply-To: <199509260631.CAA15855@healer.com> from "Coranth Gryphon" at Sep 26, 95 02:31:31 am

next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
> 
> What functionality does the "rc?.d" sym-linked subdirs method gain over
> the control file model?

directory editing operations are designed to be atomic to an item
editing a file is a much more complex operation, particularly INSERTING
something into the right place, assuming that you have no 
human doing it..
(not saying impossible, but
ln -s ../sbin/init.d/foobar S56foobar

is a LOT simpler to impliment than 
a program that runs through a file looking for the correct place to
insert things..
The only other simple way of doing it would be:
echo "S56 foobar" >> startfile


and on startup..
files=`sort <startfile|grep "^S"| awk '{print $2}'`
for file in $files
do
  sh -c $file start
done

and you can't convince me it's less likely to break down than option 1




> 
> > |>  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.
boy was this ever correct
> 
> 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.

great until someone edits it by hand during an emergency..
"I had to do it to get the system up"

> 
I think a slightly simpified version is SIMPLER than the BSD system
once you think about adding packages

> 
> > 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?

I seen inittab annd init.d as two ORTHOGONAL items..
you can have init.d even with only one run-level

inittab is just a generalisation of /etc/ttys,
(or put another way, /etc/ttys is a crippled inittab.
> 
> What does the "inittab" your proposing gain over just the "rc?.d"
> directories with numbers dictating script order?

the two are orthogonal issues.
we can discuss tehm separatly!

> 
> > We also want the individual service scripts to be the identical for
> > both methods.
> 
> Definately.
YES
> 
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509260702.AAA09174>