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/ slangasek@ubuntu.com vorlon@debian.org
From 9afbe359340924c87f19388925c93026c8711fe1 Mon Sep 17 00:00:00 2001
From: Steve Langasek <vorlon@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
Attachment:
signature.asc
Description: Digital signature