init script generators ( was: Re: proper handling of communication channels in debian)

Erich Schubert erich.schubert at gmail.com
Thu May 3 14:51:43 UTC 2007


Hi,
> > I posted a proposal to the list here to use /proc/1/exe for detecting
> > which init system is currently running (and then invoking the
> > appropriate /etc/init-tools/invoke/foobar etc. commands). I don't know
> > if anyone has investigated this closer.
>
> This will flag which initscript is being run *on that cointainer* in
> virtualized systems.  But it will do the wrong thing on regular chroots.

So any other proposal on how to properly detect the init being used?
Should we patch all init systems to setup some protected shared memory
or so that we can use to query or so? Note that we have to assume no
filesystem to be writeable and keep the data available from early
bootup until shutdown time.

> 1. Avoid crap formats, PLEASE.  Either use XML or have two files, one with
> the metadata in a easy to parse format that has no [foo] windows-.ini crap,
> and the other with the real data.

I agree with you on that one. However I think we'll have a hard time
selling XML. Even though the scriptlets are 'exported' to whatever
init is needed, so XML only needs to be available at install time.
>From a 'people will adopt it' point of view, I think the
debian/control kind of format is best, but it might be too limited.
(i.e. key: value pairs, continuation lines start with whitespace). And
UTF-8, no other charsets allowed.

> XML may be heavy, but at least it *always* gets CDATA and charsets right,
> even when you have to mix them.  Reinventing the wheel is not a good idea.

We don't need multiple charset support, we can require the files to be
in UTF-8, for example.

> 2. Remember that reading an entire directory of files is *SLOW* on ext3, but
> that resilience is more important than anything else in a init script
> system, so both have to be taken into account.  If you place everything in
> one file, use a format with extremely strict validation capabilities to flag
> any possible corruption right away.  And add a fsck-like thing for it.

Seconded, too. But I don't think we'll have much influence on what
formats the different init systems accept. If we'd be patching them to
be able to process the meta-init-scripts directly, we could write yet
another init right away.

s/fsck/lintian/.

As for features of the existing init systems - that's why I said that
in a first step, the init maintainers and developers should talk about
their requirements and such. There IMHO is much too little
communication on such issues, everybody is like working on their own
init without talking much to the others.

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



More information about the initscripts-ng-devel mailing list