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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130417220336.gg1...@codelibre.net
