tags 591791 patch thanks Hi there,
Attached is a tentative patch for this bug that documents what I think the requirements are both for alternative init systems in general, and for upstart in particular. Sorry this has taken so long; I spun my wheels on it for some time because I couldn't quite accept that there were so few additional requirements that needed to be specified here! I still don't entirely believe it, so please let me know if you see anything that I've overlooked. :) Also, it's possible that some of the bits I've marked as upstart-specific will also be applicable to systemd and should be moved up a section. I'm not familiar enough with the mechanics of systemd to say whether this is the case; eyeballs/wording tweaks welcome. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
From 9afbe359340924c87f19388925c93026c8711fe1 Mon Sep 17 00:00:00 2001 From: Steve Langasek <vor...@debian.org> Date: Sun, 9 Jan 2011 19:58:58 -0600 Subject: [PATCH] Document generic and upstart-specific init-system requirements Add a new section on alternative init systems that outlines the compatibility requirements for both init replacements and packages shipping upstart jobs. Closes: #591791 --- policy.sgml | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 59 insertions(+), 0 deletions(-) diff --git a/policy.sgml b/policy.sgml index 642f672..1c89ffe 100644 --- a/policy.sgml +++ b/policy.sgml @@ -6968,6 +6968,65 @@ Reloading <var>description</var> configuration...done. </p> </sect> + <sect id="alternateinit"> + <heading>Alternate init systems</heading> + <p> + A number of other init systems are available now in Debian that + can be used in place of <package>sysvinit</package>. Alternative + init implementations must support running SysV init scripts as + described at <ref id="sysvinit"> for compatibility. + </p> + <p> + Packages may integrate with these replacement init systems by + providing implementation-specific configuration information about + how and when to start a service or in what order to run certain + tasks at boot time. However, any package integrating with other + init systems must also be backwards-compatible with + <package>sysvinit</package> by providing a SysV-style init script + with the same name as and equivalent functionality to any + init-specific job, as this is the only start-up configuration + method guaranteed to be supported by all init implementations. An + exception to this rule is scripts or jobs provided by the init + implementation itself; such jobs may be required for an + implementation-specific equivalent of the <file>/etc/rcS.d/</file> + scripts and may not have a one-to-one correspondence with the init + scripts. + </p> + <sect1 id="upstart"> + <heading>Event-based boot with upstart</heading> + + <p> + Packages may integrate with the <prgn>upstart</prgn> event-based + boot system by installing job files in the + <file>/etc/init</file> directory. SysV init scripts for which + an equivalent upstart job is available must query the output of + the command <prgn>telinit --version</prgn> for the string + <tt>upstart</tt> and avoid running in favor of the native + upstart job. + </p> + <p> + Because packages shipping upstart jobs may be installed on + systems that are not using upstart, maintainer scripts must + still use the common <prgn>update-rc.d</prgn> and + <prgn>invoke-rc.d</prgn> interfaces for configuring runlevels + and for starting and stopping services. These maintainer + scripts must not call the <prgn>start</prgn>, + <prgn>restart</prgn>, <prgn>reload</prgn>, or <prgn>stop</prgn> + commands directly. Instead, implementations of + <prgn>invoke-rc.d</prgn> must detect when upstart is running and + when an upstart job with the same name as an init script is + present, and perform the requested action using the upstart job + instead of the init script. + </p> + <p> + Dependency-based boot managers for SysV init scripts, such as + <package>insserv</package>, may bypass a given init script + entirely when an equivalent upstart job is present, to avoid + unnecessary forking of no-op init scripts. + </p> + </sect1> + </sect> + <sect> <heading>Cron jobs</heading> -- 1.7.1
signature.asc
Description: Digital signature