Hi Tollef, Picking up this policy thread after a bit... Let's see if we can drive this to a conclusion now. On Fri, Feb 04, 2011 at 10:11:40PM +0100, Tollef Fog Heen wrote: > >From the proposed policy patch: > + 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. > My system actually already has upstart installed, but doesn't use it, so > upstart's telinit will have to be fixed to not report «upstart» in its > version string if the running init is not upstart. That's slightly > orthogonal to this bug report, but it shows that you can't necessarily > depend on the output of --version and such to know what's running. This > will also affect people on migration from one init system to another. Right. I've looked around, and the better interface to use here is 'initctl version'; this command tries to query the running init daemon over the upstart-specific control socket and fails if it can't connect. Of course, if the initctl command doesn't exist at all on the system, this will fail. > + 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. > What happens to the dependency resolution of insserv in that case? I'd > much rather have insserv not do anything and the non-sysvinit init > system be smart and parse LSB headers rather than insserv seeing that A > depends B, but B is missing (since it's provided by a systemd > service/upstart job) and then flake out. This was a good question, which took me a while to answer. The answer I've come up with is <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2011-October/005345.html>. It's a deliberate design decision for upstart to not support parsing of LSB headers of init scripts, instead delegating this to insserv (and delegating the execution to /etc/init.d/rc). The linked patch, however, allows startpar to recognize when a dependency should be satisfied by an upstart job instead of by the corresponding init script. > I'd also like us to forbid depending on implementation-specific scripts > such as mountkernfs since there won't necessarily be anything that maps > to in a non-sysvinit world. The exception would be if an init script is > shipped as part of the init system, so sysv-rc's scripts could have > dependencies on mountkernfs, but random daemons could not. udev already depends on mountkernfs as part of the rcS sequence. Of course, the entire rcS sequence should be replaced by the alternative init system, but this will still require cooperation between several packages. I'm not sure whether this needs to be documented in Policy per se, or with what level of granularity. I do think there's a bootstrapping tangle here, in that I don't want to start pushing patches to sysvinit, lsb-base, and debhelper until we have the basic Policy agreed upon, and I don't think we'll be able to discern a correct policy for things like mountkernfs until we've gotten fairly far along with implementing it. So if you don't mind, I'd like to split this particular issue off to be dealt with separately. > A final thing I'd like to get added to the policy text is how > standardised facility names are handled. insserv for some reason does > not handle init scripts providing $x-display-manager and similar, but > requires those to be added to the insserv configuration file. We should > either require init implementations to allow providing the standardised > facility names or we should put that information somewhere in a a > neutral location and format so all init implementations can make use of > it. Does this refer to aliases standardized in the LSB, or to some other standard? (I'd answer this for myself, but once again it looks like I can't find the text of the LSB when I'm looking for it...) 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 06b2b04a925acd4acab2697c8b62ace9a24364a6 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 | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/policy.sgml b/policy.sgml
index 38f2096..da52d81 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7138,6 +7138,68 @@ 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.
+ </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 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>
<heading>Cron jobs</heading>
--
1.7.5.4
Attachment:
signature.asc
Description: Digital signature