Designing a new init: configuration

[Erich Schubert]

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