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 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
