Re: administration of initscripts
On Wed, Apr 17, 2013 at 08:55:42PM +0200, Thilo Six wrote:
> Hello Roger
>
>
> Excerpt from Roger Leigh:
>
> >>> update-rc.d foo disable|enable
>
> -- <snip> --
> >> It might be a nuisance but running the stop part of the initscript isn't the
> >> same as not touching it all?
> >
> > Sorry, I don't quite understand the question here. update-rc.d
> > never starts or stops anything--all it does is adjust the rc.d
> > links.
>
> 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.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Reply to: