Re: /etc/init.d structure [long rant]
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:
>
<rant off>
This is rediculous. Just don't install the sysv-init stuff
and run a bsd init + rc.local. By the by, BSD systems do a
very sysvr4 kind of modular startup these days anyway --
because its better. As far as easy to tell what's going on,
just look in the run control directory for whatever run
level you want to examin! You don't even need a friggin'
editor! Just because linux distributions have done a piss
poor job of implementing the sysvr4 startup configuration,
it doesn't mean its a bad idea. We should just do it right
instead of hacking sysvinit to work like an rc.local
monolothic startup.
If you want to see how its supposed to work, look at
Solaris 2.x, Irix 6.x, etc.
I've rewritten rc to do just that somewhere, but I wound up
having to undo whatever debian does _every time I added a
package_! It became too much work, so I bagged it.
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.
Debian currently only correctly defines rc.boot, rc0.d,
rc6.d and rc1.d. the "multi-user" run levels are all
defined the same. This is absurd. Having run levels
defined for a specific purpose is what they're there for.
Why it is we don't do that is beyond me. I can remmber
having this discussion before and the conclusion was that it
would be too complex to actually define run level 2 as a
"multi-user network client" configuration, run level 3 as
"multi-user network server" configuration and level 4 as
some variation of run level 2. That would leave run level 5
for "power down" once more hardware supports it, and 7, 8,
and 9 as possible variations on multi-user run levels, or
"failover" run levels assuming responsabilities for a failed
server somewhere else on the lan.
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.
This capability -- to define multiple possible running
"states" -- has been around for a while, and its much better
than MS's "dynamic" profiling. I used to have a laptop with
run levels defined for "standalone", "docked", "no xdm",
"NY", "HK". Using debian's scheme, I needed to have
everything defined in every run level (2,3,4,7,8). In
reality, I should have been able to define run level two as
the default, and the others as diffs from that state.
Show me how to do that with rc.local -- without hacking it
to work like sysvinit.
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.
<rant off>
--
"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: