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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
