On Mon, Dec 26, 2011 at 11:04:27AM -0800, Russ Allbery wrote: > > The patch seems mostly ok to me. I think we should decide whether we > > want a single invoke-rc.d that everybody uses and which knows how to > > handle all of sysvinit, upstart and systemd or if we want each init > > system to ship their own. From the patch, it looks like each init > > system should ship their own, but that it still must keep compatibility > > with all other implementations. > I agree that this should be spelled out, since the behavior of invoke-rc.d > is rather important in this proposal. Currently, it says: > 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. > in the upstart section, which implies *all* implementations of > invoke-rc.d, including the one that comes with sysvinit. Was the > intention that this would only apply to the one that comes with upstart > itself? So currently, invoke-rc.d is part of the sysv-rc package, and there's an alternative implementation in the file-rc package. I had envisioned that these packages would continue to own the invoke-rc.d and update-rc.d interfaces, as they do on Ubuntu, and be the focal point for bridging the differences between the different init systems. I didn't mean that the init systems themselves should implement invoke-rc.d, but that the one coming with whichever implementation of "rc" is used on the system should support all the init systems. Shipping an invoke-rc.d implementation in upstart and/or systemd would mean either a lot of code duplication, or a pass-through with dpkg-divert. I'm not enthusiastic about either idea, but if push came to shove (i.e., if the sysvinit maintainers rejected patches to support upstart in invoke-rc.d), I would opt for the latter. > Also: > Dependency-based boot managers for SysV init scripts, such as > <package>insserv</package>, may avoid running a given init script > entirely when an equivalent upstart job is present, to avoid > unnecessary forking of no-op init scripts. In this case, the boot > manager should integrate with upstart to detect when the upstart job > in question is started or stopped to know when the dependency has been > satisfied. > This is optional, but I'd still like to get review of this part from the > insserv maintainers. (Did that happen somewhere earlier in this thread > already?) Bug #660824, with initial positive feedback from one of the sysvinit comaintainers. (This should be corrected to say "startpar" rather than "insserv" since insserv only generates the dependency information, it's startpar that acts on it at boot time. Fixed in my patch.) > Don't we need to say something about how alternative boot managers should > arrange to take over init, given that sysvinit is Essential, so that we > don't break things while doing so? I guess that's bug #645540, and subsequent discussion on debian-devel in http://lists.debian.org/debian-devel/2012/02/msg00309.html ff. Policy doesn't really speak to this at present anyway, so I would be content to let the maintainers of the small set of packages involved figure this out among themselves. > Finally, given the recommendation: > SysV init scripts for which an equivalent upstart job is available > must query the output of the command <prgn>initctl version</prgn> for > the string <tt>upstart</tt> and avoid running in favor of the native > upstart job. > I'd really like to see Policy provide some sample code for how to do that, > since otherwise people are going to get this wrong. Ok, example included based on the patch in bug #661109. Updated patch attached. Thanks, -- 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 4542bf3f70be85e0e6eecd754c8530ebf2c71a77 Mon Sep 17 00:00:00 2001
From: Steve Langasek <steve.langasek@canonical.com>
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 | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/policy.sgml b/policy.sgml
index b3c5886..b390db2 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7188,6 +7188,74 @@ 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>initctl version</prgn> for the string
+ <tt>upstart</tt> and avoid running in favor of the native
+ upstart job, using a test such as this:
+ <example compact="compact">
+if [ "$1" = start ] && which initctl && initctl version | grep -q upstart
+then
+ exit 1
+fi
+ </example>
+ </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
+ <prgn>startpar</prgn>, may avoid running a given init script
+ entirely when an equivalent upstart job is present, to avoid
+ unnecessary forking of no-op init scripts. In this case, the
+ boot manager should integrate with upstart to detect when the
+ upstart job in question is started or stopped to know when the
+ dependency has been satisfied.
+ </p>
+ </sect1>
+ </sect>
+
<sect id="cron-jobs">
<heading>Cron jobs</heading>
--
1.7.9
Attachment:
signature.asc
Description: Digital signature