Re: Faster boot by running init.d scripts in parallel
Petter Reinholdtsen wrote:
>
> One "hidden" feature of the current Debian boot sustem, is the ability
> to run the init.d scripts in parallel.
>
some years back, richard lightman wrote depinit. it's a complete
replacement for sysvinit, and it's a parallel initialisation system.
unlike sysvinit, it caught _all_ signals on applications.
i installed it several times, and it showed that startup time could be
reduced from 2 minutes (800mhz PIII) to 25 seconds, and it showed that
shutdown time can be reduced from 1-2 minutes to under 4 seconds.
the reason for the fast shutdown time is that a) shutting down services
typically takes a lot less time than starting them b) depinit would send
increasingly drastic signals to kill a service.
other nice features include:
* monitoring and chasing with extreme aggression anything that looks like
it's out-of-control. applications such as rootkits, which spawn child
processes immediately on startup and on the death of the parent, are good
candidates and were the driving force behind the decision
* script / service chaining (applying the unix pipe philosophy, even to
services). one "service" can output its stdout and/or stderr to _another_
service. richard utilised this e.g. on sshd and other services requiring
authentication. by chaining the output from sshd into another script, he
could monitor attacks against a server _live_ rather than "ohh let's run a
cron job every minute and watch the sshd logs or something oh whoops, too
late". so, the monitoring script could observe three login failures and
*instantly* add a firewall rule.
* automatic re-spawning of services AND termination of dependent services if
re-spawning fails. this is a really important security feature. if the
firewall doesn't come up, or any other particularly critical service (such
as heartbeat monitoring service), do you REALLY want the dependent services
to come up? automatic re-spawning basically does away with the [stupid]
mysql monitoring script, which cannot do a proper job anyway, simply because
the required signals cannot be properly caught [remember: depinit catches
EVERYTHING].
that's not all - it's just everything i can remember.
when i installed depinit, i had to spend considerable time customising
udevscripts, in order to get some speed. the kinds of systems i was
installing it on were waiting for 30 seconds on /sbin/udevsettle, due to the
absolutely ridiculous numbers of pseudo ttys created by the debian linux
kernel. 768 pseudo-ttys!!! come _on_. so, i broke it down into stages.
the first udevsettle "service" created /dev/ttyNN and /dev/pty/NN and the
second one would create and wait for /dev/ttyNNN and /dev/pty/NNN. critical
services would then depend on the first udev service (such as filesystem
mounts, networking, sshd etc) and non-critical services on the second. this
trick was what got most of the boot time down.
[btw it has to be said that udev and the udev scripts are an absolute dog's
dinner. the amount of cpu time wasted by spawning /bin/sh 12 levels deep,
almost a thousand times, is .. um... considerable.]
also one other observation was that many of the scripts these days do _lots_
of "sleep" cycles. putting all of these in serial is a _total_ waste of
time.
also, richard observed that sysvinit [non-parallel] was created when
context-switching was insanely expensive. CPUs now - even low-end ARMs -
are pretty damn good at context switching. it's therefore absolutely
pointless to stack initialisation scripts up in serial, even on a single CPU
system, in the pretense of saving cycles, when you can throw out a hundred
processes in parallel on most CPUs of the past decade and they'll not even
break a sweat.
anyway - i wanted to mention this because depinit remains absolutely streets
ahead of anything else i've encountered,
l.
--
View this message in context: http://www.nabble.com/Faster-boot-by-running-init.d-scripts-in-parallel-tp25381465p25530129.html
Sent from the Debian Devel mailing list archive at Nabble.com.
Reply to: