Re: administration of initscripts

[Thilo Six <T.Six@gmx.de>]

Hello Roger


Excerpt from Roger Leigh:

-- <snip> --
>> Yes, the man page says it swaps the S for a K.
>> e.g. say we have the following link:
>> /etc/rc2.d/K10cups
>>
>> Then afaik - and please correct if i am wrong - init will call the stop part of
>> this initscript when ever runlevel 2 is entered. So basically during each boot
>> process. Why should we spent resources on that?
>> Therefor rc-update() places those links instead only in runlevel 1 where they
>> might even be useful without wasting time on them during bootup, nor shutdown.
> 
> This is simply how System V init works when runlevels change.  You do
> need the links in each runlevel so that you stop all the necessary
> services when leaving the runlevel, and then start all the necessary
> services entering the new runlevel (i.e. you run all the K links in
> runlevel n, and then all the S links in runlevel m).  You can remove
> "unnecessary" links, but then you'll find that things won't then be
> stopped if you switch runlevels/shut down etc. in the "wrong" order.
> 
> However... that's how it works traditionally.  Current Debian uses
> startpar to effect runlevel changes, and it has both the links and the
> /etc/init.d/.depend* dependency graphs as input.  It can potentially be
> quite a bit cleverer in avoiding running scripts unnecessarily.  I
> haven't checked if it does or not though--it would be interesting to
> know.
> 
> Note that the overhead of running a script that exits immediately is
> almost unnoticeable.  For all but the most exceptional circumstances,
> eliminating these scripts being run is not worthwhile.  A quick test
> on my system shows that I can run (sequentially) up to 2300 shell
> scripts *per second* or (parallel) potentially around 8 times that,
> i.e. over 18000.  This is a decent system, but even on a slower system,
> it's not worth optimising stuff that's lost in the noise--there are far
> greater things that slow stuff down--like actually starting and stopping
> stuff--and this is all parallelised now anyhow.  If you were to optimise
> this, you'd save a tiny fraction of a second.

Thank you for the insight. This is interesting. I will keep this in mind, though
i probably wont send another update of rc-update() to this list as people are
getting bored presumably.

Thanks.
-- 
Regards,
Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6  7C18 89A4 A2A0 C70B 1A8F