Re: [LONG] RH refugee comments & questions
On Tue, Apr 15, 2003 at 06:00:49PM +0200, Patrice Fortier wrote:
> Why are the default values S20 & K20? Are all the services supposed to
> be started at S20? I guess not.
You guess correctly. But that's the point of default values - you're
supposed to override them when they don't make sense. To put it
another way, starting everything at S20 is no better or worse than
starting everything at S99. A default value had to be picked and S20
was chosen.
> In other words, I wonder if update-rc.d was created to be used in post-install scripts
> with the correct values only. It's not for the average admin who'd like to have an
> hint on a default value for SK values of a network service.
> I know that every server is different, and default values can change, but 20...
If I understand correctly (having never used Red Hat much and knowing
vary little about chkconfig beyond assuming that it's the part of the
boot sequence that always stops and makes me wait while it checks for
hardware changes[1]), you want update-rc.d to include a database of
default S/K values for all services. No thanks; I'd rather not have
to install a new sysvinit package every time a new service gets
packaged.
Personally, I figure that if you know enough to be using update-rc.d
by hand, then you probably know enough to figure out what S/K values
you want on your own. For those who are less-experienced, just let
dpkg handle it or accept the default values.
> Some people look in rc?.d/* to see if a package is installed, I just look in init.d/
> (I don't like having too much stuff in rc?.d/: it's less readable, and a waste of
> time at boot).
Agreed. Looking in init.d is more reliable, as well.
> My problem is when I want to reactivate a service. With chkconfig I can
> do it like a charm. With update-rc.d I have to remember all the parameters,
> or maybe look at the postinstall script (didn't check this, so I may be wrong
> on this one :)).
On the (exceedingly rare) occasions when I want to temporarily
disable something, I do it with mv S->s. Prevents the startup and
preserves the information on when it should fall in the startup
sequence.
> This second problem is much disturbing for me:
> playing with update-rc.d I saw that it was generating a rc2.d/S20apache.
> Starting apache at run level 2???
> Looking in /etc/inittab, I also found:
> id:2:initdefault:
>
> Why does debian use the run level 2 instead of 3, as usual, to activate
> network?
Debian policy is to configure all run levels from 2-5 identically and
leave it to the local admin to customize them as he sees fit.
> Why the hell did the debian developpers changed that?
They didn't. Debian has been doing it this way since before LSB
existed.
> An other feature that I miss is the [ OK ] [FAILED] at boot for the
> rc?.d/ stuff. You can think it's just a fancy thing, and in fact you're
> right as long as there is only green OK displayed on the screen.
> The red FAILED displayed is very interesting, especially when you
> expected that everything should be fine.
A red FAILED may work for you, but I'd rather see the actual error
message generated by the service. (But, again, I'm not very familiar
with Red Hat. About the only FAILEDs I've ever seen have been
attempts to start gpm with no mouse present.) I can't stand it when
the OS decides to gloss over the startup sequence instead of showing
me what's actually going on.
[1] If I've made a hardware change that matters, I'll tell you,
dammit! Don't waste my time checking for changes every time the
system boots on the off chance that this might be the one time in a
hundred that something new has been added.
--
The freedoms that we enjoy presently are the most important victories of the
White Hats over the past several millennia, and it is vitally important that
we don't give them up now, only because we are frightened.
- Eolake Stobblehouse (http://stobblehouse.com/text/battle.html)
Reply to: