Designing a new init: configuration

[a-aa]

Erich Schubert wrote:

>Hi,
>Okay, lets assume we are designing a new init. Please ignore the fact
>that we havn't decided on any objectives yet, nor on anything else of
>the architecture.
>Let's talk about the configuration. Which is probably the most
>important thing after doing whats its expected to.
>
>Which configuration style do you prefer, what syntax e.g. for
>depenencies do you want?
>
>1. First approach is probably the classic - init scripts.
>There is no real syntax specification, except everybody uses shell scripts.
>Dependencies could be handled either using LSB style comments
>http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html
>
>Drawbacks I see:
>- needs special parser for LSB information
>- no/difficult status feedback into init system about availability
>- no direct monitoring/respawn of daemons
>Benefits:
>- LSB compliance
>- wide support in short timeframe
>
>Syntax:
>init scripts as usual and special comments in there.
>
>2. Extended commands in init scripts - the simpleinit/need/provide approach
>We have init scripts as usual, but there are extra commands, namely
>need and provide for init scripts to ensure dependencies. Basically a
>set of "requested" init scripts is started.
>the need commands - e.g. "need portmap" will try to start the
>requested services additionally, "provide mail-server" will flag a
>service as available.
>Examples:
>http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/
>http://john.fremlin.de/programs/linux/jinit/
>
>Benefits:
>- simple modifications to init scripts
>- existing implementations
>Drawbacks:
>- no monitoring/respawn
>- no notion of started vs. running
>
>Syntax:
>init scripts and special commands like "need portmap || exit 1"
>
>3. Daemontools / minit approach
>Each service has its own directory. The "run" link/script is used for
>starting the service, additional files such as "depends" (services
>which need to be up first), "params" (parameters for run command),
>"respawn" (restart service when it terminates), "sync" (assume service
>is up when finished, not when forked) contain additional options.
>Minit Howto: http://www.fbunet.de/minit.shtml
>
>Benefits:
>- no need for a config parser - allows for minimal init implementation
>- easy to configure
>Drawbacks:
>- nonstandard configuration
>- configuration has issues with package upgrades (deleted option files
>might reappear)
>- console output handling
>
>4. initng approach
>Each service has a config file, which contains options and flags as
>well as shell code fragments for setup, start, stop
>http://initng.thinktux.net/index.php/Developer_Documentation_How_to_make_a_service.
>
>Benefits:
>- config file format easy to extend with new options (chroot/setuid/...)
>- very flexible and extensible
>Drawbacks:
>- needs a parser in core init
>- another config file format to learn for admins
>  
>
I should mention that I wrote rcparser a while ago as a initng plugin,
proof of concept, that boots using /etc/init.d sysv scripts, it was
rough, but not as much as I thought it'd be.

>Runit is AFAICT a mixture of 2 and 3? (svwaitup ~ need, run command like minit)
>Anything I missed? Is there another different config format?
>(Oh, I probably skipped the all-in-one-file format...)
>
>best regards,
>Erich Schubert
>--
>    erich@(mucl.de|debian.org)      --      GPG Key ID: 4B3A135C    (o_
>  To understand recursion you first need to understand recursion.   //\
>  Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für   V_/_
>        eine Stunde wie eine Heimat aus. --- Herrmann Hesse
>
>_______________________________________________
>initscripts-ng-devel mailing list
>initscripts-ng-devel at lists.alioth.debian.org
>http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
>
>  
>