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

[Sven Mueller]

Fabrice LORRAIN wrote on 18/04/2007 22:44:
>  From [1] you can currently read [2] which is stating the following :
> 
> "This BoF comes out from several ideas posted in Planet Debian by Erich 
> Schubert, Sven Müller, Joachim Breitner, Mike Homey and myself (so far)."
> 
> Hmmm, this should really had come out as "THis BoF comes out from 
> several ideas posted in the initscripts-ng-devel list by etc....".
> 
> Blogging about technical point concerning debian is cutting everybody from :
> - archives = memory
> - participating
> 
> A cut&paste of what has been aggregate on planet.d.o in the wiki would 
> be nice(. Some answers on private blog where interresting to.

For simplicity, I'm posting a cut and paste of my most recent blog entry
on the topic here, but I currently don't have the time to put it on the
wiki:

http://blog.incase.de/index.php/2007/04/17/init-script-generators/

Posted in Computers, PlanetDebian at 20:34 CEST (+0200) by sven

Gunnar [0] is following up on the init script blog posts by Erich and
me. First a note to Gunnar: The idea of the init scrip snippets isn’t
exactly my own idea, but rather taken from a comment to one of Erich’s
posts (IIRC), I don’t know the original author anymore.

Anyway, I really think that some init script generator should work. It
should even be possible to fetch variables from
/etc/default/<daemon-name> if needed. I’m just doing a braindump of what
I have in mind for the start and stop of a daemon. I would expect a
configuration file (currently I think one for each operation might be
best, but INI-lookalike files might also be OK). So for the start
operation, I would expect these options:

   1. simple daemon, uses a default config with a hardcoded path and
      needs no options or only static options passed:

      [SIMPLE]
      /path/to/daemon
      option 1
      option 2
      option 3

      Where I chose to name one option per line so whitespace and
      controll characters can be part of the options without the need to
      quote anything.
   2. a bit more complicated, needs a few variables from
      /etc/default/daemon:

      [TEMPLATED]
      /path/to/daemon
      option 1
      %PARAMETER_FROM_ETC_DEFAULT%
      --parameter=%ANOTHER_ONE_FROM_ETC_DEFAULT%

      Where the script generator would have to make sure that the
      parameters from /etc/default are filled in at runtime. I would
      expect POSIX-Shell-Scripts in /etc/default for this.
   3. Really complex: A custom script snippet is needed which has to do
      some specificc tasks, like cleaning possible stable locks which
      had been left behind.

      [SCRIPT]
      rm /var/lock/daemon.lck
      /path/to/daemon --background --and --other --options

      Where the script generator would simply take this script and use
      it where it would otherwise generate its own code.

As for stopping, I generally see only three options for the sysv-like
background processes: Either a script is needed (see above for how that
would look like) or a process needs to be killed according to a PID-file
or the process name (with the later being rather bad). So this would
result in:

   1. [SCRIPT] like for starting the daemon
   2. killing by PID-file:

      [PIDFILE]
      /path/to/pid-file

   3. killing by process name/executable:

      [PROCESS]
      binary

      or

      [PROCESS]
      /path/to/binary

      where the generator would either only look at the name of the
      process (first version, no full pathname) or for a process with
      the given executable (from /proc/ /exec, I would expect).

Alright, this would leave the cases of running (instead of
backgrounding) the server and stopping such a running server (the later
should be fairly simple unless the stopping of the server requires
additional actions other than simply killing it) as well as the
reload/restart/status stuff. But these should also be relatively simple
actually.

What would be interesting for me:
Does any init system require information that is not part of the
following list? I would plan with supplying information how to:

    * start server in background
    * start server in foreground (without the need for a terminal)
    * determine wether a server runs (status)
    * determine wether a server is ready to serve requests
      (also part of status)
    * determine wether the server is installed (and able to be started)
    * stop a background server
    * stop a foreground server (unless specified, a simple SIGKILL to
      the process is assumed)
    * restart foreground server (unless specified, a simple stop-start
      cycle is assumed)
    * restart background server (unless specified, a simple stop-start
      cycle is assumed)
    * reload config (unless specified, it is assumed that reloading
      doesn’t work and a restart is needed)
    * reopen logs (unless specified, the “reload config” operation is
      assumed to do this)
    * some meta information: short description, needs writeable
      filesystem(s) mounted, needs a certain daemon to be running
      already (or even: able to serve requests), enhances other daemon X
      and should be started before it (don’t care if X isn’t
      installed/configured), is enhanced by daemon Y and should be
      started after it (don’t care if Y isn’t installed/configured),
      replaces daemon Z, should only run once at startup, …

Finally, even with all that information available inside a Debian
package, this would still leave one question unanswered: Who triggers
init script generation? If a daemon package does so in postinst: How do
I switch to a different init system? If the init system does it in
postinst: What happens to additional daemons installed later on? If they
get regenerated during system start: How much penalty does that cause?
Currently I think the route to go is to provide a command to daemon
packages’ postinst that (re)generates only the needed scripts for that
package and have a command used in an init system’s postinst which
regenerates all of them. That should do. Regenerating during boot would
most likely take too much time and has other problems, too, like the
availability of a writeable filesystem to store the generated scripts.
Alright, if someone would like to see this post (or rather parts of it)
on the Wiki page about an Init HackFest[1], please transfer it there
yourself. I’m currently not able to log in, for whatever reason.

[0]http://gwolf.org/index.php?gadget=Blog&action=SingleView&id=Init-followup
[1]http://wiki.debian.org/HackFests/Init

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 188 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/initscripts-ng-devel/attachments/20070502/7dba5010/signature.pgp