Re: Faster boot by running init.d scripts in parallel
On Sun, Sep 20, 2009 at 13:52:59 -0700, lkcl wrote:
[...]
> 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:
[...]
> * 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].
Maybe you are interested in the runit init system, as depinit sounds
similar. It doesn't directly support dependencies, but it runs a
service through a pipe and not as a daemon in the background, so that
supervision and direct submission of signals is possible.
Regards,
Tino
Reply to: