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 >[email protected] >http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel > > > _______________________________________________ initscripts-ng-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
