On Sun, Jan 09, 2011 at 08:10:04PM -0600, Steve Langasek wrote:
> 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.
Next to upstart and systemd we currently also have file-rc and runit
as alternatives to sysvinit. But runit-run doesn't seem to exist
anymore?
> + 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>
A lot of the scripts currently in /etc/rcS.d/ come from the
initscripts package. Is the alternative supposed to implement
all the functionality by those scripts? Or do we expect them
to run the scripts from /etc/rcS.d/ as 9.3.4. seems to suggest?
What should packages do that want to have their script run
at that time? For sysvinit scripts this is calling update-rc.d
with S as the runlevel. I don't know if the alternatives
support something like a runlevel, and which they support.
> + <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.
/etc/init seems to be a very general directory name for an upstart job.
Can the alternatives use the same job files as upstart?
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.
"telinit --version" with sysvinit now returns:
telinit: invalid option -- '-'
Usage: telinit {-e VAR[=VAL] | [-t SECONDS]
{0|1|2|3|4|5|6|S|s|Q|q|A|a|B|b|C|c|U|u}}
What kind of output would you expect from it?
If I understand you right, if the package supports something
other than sysvinit, the file in /etc/init.d/ should check that
any of those is currently used? And it should just return 0?
I wonder if it would be useful to call invoke-rc.d instead
in that case if it's run by a user.
> + </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.
That's already covered by 9.3.3.2? (But could use rewording.)
What I miss in policy is a description of update-rc.d. We
currently seem to have 2 implementations (each with it's
manpage) of it while I was expecting each alternative to
implement this. And I guess the same goes for invoke-rc.d.
9.3.3.1. could use a re-write as it also seems to be sysvinit
specific.
Kurt
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110110201733.ga2...@roeckx.be
