[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /etc/init.d structure [long rant]



On Wed, 13 Aug 1997, Richard G. Roberto wrote:

> On Tue, 12 Aug 1997, Peter S Galbraith wrote:
> 
> > There was a discussion about this recently... So I thought I'd mention this:
> > This is posted on cola; looks neat to me:
> > 
[snip]
> The premise is that a run level is _clearly defined_ and
> managed according to a schema.  Debian just shotguns links
> in everything that looks like a run control directory under
> /etc (practically).  A real sysr4 rc script should run all
> K* scripts in a run control directory, then all S* scripts,
> starting with rc1.d, incrementally up to the defined run
> level.  This means that having stuff in rc1.d and rc2.d is
> totally redundant.  Likewise for rc2.d and rc3.d, etc.
> After the defined default run level is achieved, changing
> run levels occurs by simply running the K* scripts in the
> new run level, then the S* scripts.
>
So excuse me if I have got this wrong, but does that mean going from run
level 2 to run level 7 requires running all K* then S* in run level 3,
then all K* then S* in run level 4, then all K* then S* in run level 5,
... all the way up to run level 7? And going from run level 4 down to 2
does the same in reverse?

Doesn't this mean that with something that has an S* in runlevel 3,5,7 and
a K* in 2,4,6, that it will be started, stopped, started, stopped... all
the way through? What about going through a runlevel 5 which is for "power
down"?

What I thought would be more sensible is to know what needs to be running
at each runlevel, and when you change runlevels, do a "diff" on the two
runlevels, kill everything in the first but not in the second, and start
everything in the second not in the first. This allows you to transition
faster between arbitary runlevels, and avoids transitioning through
runlevels you don't want to touch on the way.

This sort of scheme can be implemented in a variety of ways, including
config files, or S* symlinks in rcn.d directorys (no need for K* anymore).
I don't want to introduce yet another way of doing it, but it just seems
to make more sense to me.

[snip]
> The issue arose when package maintainers had to classify
> their packages as to falling into one of the categories
> described.  Some client process are dependant on server
> processes, etc.  These would need to be sorted out.
> Obviously any local services required to make a machine fit
> the description "multi-user network client" would need to be
> started by the end of run level 2.  There were a couple of
> other gripes, but I don't remember what they were.
> 
why not just have the postinst script ask the user "what runlevels do you
want this package to run at?" and provide sensible defaults. That frees
the package maintainer from deciding what to clasify the package as, and
allows the user to have his own customized runlevels.

[snip]
> As for x86 vendors having a pow wow over how "we" should
> standardize differently than "real unix" systems do it,
> what's the point of this?  This is precisely why industry
> leaders get annoyed with "us".  Would it really be so awful
> to just adopt the "standards" of current commercial
> practice?  And no, SCO doesn't count.  Industry leaders
> currently means Solaris, HP(Hitachi)/UX, AIX, Irix, and 
> maybe DU.

I agree that an x86 only view of the world is stupid. hardware platforms
are becoming more meaningless all the time. However, I do belive that it
is worth thinking of "free" standards independantly of "comercial" 
standards. Sure we can adopt the commercial standards if they are good
enough and we are free to do so, but if they suck we should go ahead and
make our own. The free software community is large enough now that we can
make our own standards, and even sometimes make the comercial world follow
us.

This is becoming even more important now that the comercial guys are
making "open" standards in a way that ensures they have a technical edge
and is hard for the "competition" to implement.

ABO


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: