Re: /etc/init.d structure [long rant]
On Thu, 14 Aug 1997, Donovan Baarda wrote:
> 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?
No. The incremental behavior is only up to the default run
level. If there is none defined, you get prompted at
startup for a run level and I'm not sure if the system
should use the incremental method or jump right to it at
that point.
>
> 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"?
You only have K* scripts if you need to shut a process or
server down for proper operation in the new run level (or
make sure something's not running). You only have S*
scripts for the stuff you need started _for that run level_.
Run level 5 isn't implemented as "power down" yet, but it
should be. Obviously if you do an init 5, you should expect
to go down. If you set your default run level to 7, you're
in for a very short session ;) The 7, 8, & 9 run levels are
unique to linux AFAIK. They shouldn't be used as defaults
for the reason's you point out.
>
> 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.
Again, changing run levels after the default has been
reached just runs the K* then S* scripts for that run level.
We do that part right already. We just don't define the run
levels correctly. Until we do, its pointless to consider a
functional rc script since the run levels will be identicle.
>
> 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.
Well, if I run something in run level 3 that conflicts with
something in run level 4, I need to stop the service in
conflict before the run level 4 process tries to start.
That's why I can define K* scripts. This works like the
"diff" you mentioned.
>
> [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.
Flexibility is always good, and I support having a mechanism
to allow users to customize this easily (admintool? package
configuration tool?), but there should be functional
defaults shipped with the system (for everything IMHO) so
that users don't _have_ to muck around with that if they
don't want to.
>
> [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.
This argument is only viable about 4% of the time its used.
The rest of the time its just another artificial obstacle to
progress. I can remember working for a DEC var a few years
ago when they swore that TCP/IP was a unix only standard
that had little generic value and their stance was to not
get involved in "proprietary standards". Anybody see much
DECnet these days? I don't even think its available on NT
-- and they're in bed with eachother!
The point is, we're already using this "standard", we're
just not doing it right. Its just more "half assed" linux
software to commercial vendors. If there were any good
reason why we shouldn't implement this correctly, I'd be all
for it, but there simply isn't.
In any case, being committed to free software is noble, but
lets try to keep it realistic. The way rc scripts get
parsed will never become a "secret" so there's no danger in
adopting commercial practice for it. That may not be true
of driver interfaces, etc. -- but this ain't a driver
interface.
Also, I want to apologize if the language in these past
mails has been harsh. I got one mail complaining about it.
I had no intention of being offensive. I've just been
feeling quite "American" lately ;)
I do think its silly to have just gone through converting
just about every linux distribution from BSD style rc.local
to sysvinit+rcn.d run levels -- just to hack the sysvinit
methods to work like rc.local though.
Cheers,
--
"Until we extend the circle of our compassion to all living
things, we will not ourselves find peace" -Albert Schweitzer
Richard G. Roberto
--
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: