2007-04-13

Init HackFest / New init systems in Debian

Posted in Computers, PlanetDebian at 13:53 UTC (+0000) by sven

In his “Init followup” post, Erich posted a reference to his Debian-Wiki post about a proposed Debian HackFest after Etch was released (which would be about 5 days ago<smile />). Anyway, since that page at the wiki is protected, which means I can’t edit it, I’m posting my thoughts here.

I agree with Erich and some other commentors at Gunnar Wolf’s blog post that it doesn’t make sense to add X init-script-only-packages for any daemon to support X init systems. Instead, each package containing one or more daemons should contain the meta information needed to create all init scripts. Basically, this would probably include script snippets which do the following operations:

  • Pre-check: Check wether the package actually is installed rather than in removed/configured status.
  • start: Start the daemon in background mode.
  • run: Start a daemon in foreground mode (so that an exiting daemon can immediately be recognized by the init system).
  • stop: Stop a daemon running in background mode.
  • stop-running: Stop a daemon running in foreground mode. This should only be needed if the daemon doesn’t shut down nicely on a SIGTERM but instead needs some sort of message/semaphore to do so.
  • status: Return current running status.
  • reload: Reload configs, reopen logs (if supported by daemon).

Additionally, some control information would be needed including, but probably not limited to:

  • Dependencies: Should allow for alternatives, lists daemons which need to be running before this daemon is started.
  • Provides: Similar to package-provides, this should be used to allow things like replacing inetd with xinetd or something else providing similar functionality.
  • Short Description: For init systems that are capable of showing a short description next to the name of configured daemons
  • Run-Sets: Not strictly like sysvinit-runlevels, but similar, should allow the admin/user to configure different sets of daemons to start, selecting at boot by a kernel cmdline-parameter or at runtime through some command (“init 1″) which set should be running.

The script snippets listed above should allow basically any operation on a daemon, including the force-reload and try-restart commands not yet implemented by all current sysv-initscripts.

4 Comments »

  1. Joachim Breitner said,

    April 13, 2007 at 17:20 UTC (+0000)

    I basically agree (as already commented on Gunnars blog). But some remark to your proposal:

    I wonder if all these need to be script snippets. After all we also want to have fast init systems that don’t spawn lots of shells. Therefore, these should be _either_ script snippets (for complicated cases) or some kind of even higher meta data. Examples:

    * Pre-Check could list files to check for
    * run could just name a binary and parameters
    * Probably more

    Also, for daemons that support the run-scheme, no start/stop/status should be needed. If the init system relies on that scheme (eg sys-v-init) it can be derived from the run snippet.

    I’m looking forward to what becomes of this!

    Greetings, nomeata

  2. Ben Hutchings said,

    April 13, 2007 at 23:59 UTC (+0000)

    The wiki page is not specially protected. You have to be logged in to edit any page.

  3. sven said,

    April 14, 2007 at 07:31 UTC (+0000)

    Ben: This is odd. When I logged in to the Wiki before writing my Blog post, I did check the page to make sure the “protected page” message was still there after I logged in. And it was. Today though, I could edit the page. And will probably do so this evening.

  4. Gunnar Wolf said,

    April 17, 2007 at 19:14 UTC (+0000)

    [...] Leaving just as the discussion gets started is bad, yes… But I’m only now reading Erich’s and Sven’s follow-ups. Both (as well as some comments in my blog) ask why not integrating the startup links [...]

Leave a Comment