On Mon, Jan 10, 2011 at 09:17:33PM +0100, Kurt Roeckx wrote:
> 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?
file-rc is an alternative to sysv-rc, not to sysvinit; you still need
sysvinit installed if you use file-rc, and init.d scripts are the only
startup job format supported by either sysv-rc or file-rc. So I don't think
file-rc needs to be mentioned here?
runit-run seems to not be in squeeze, yes.
> > + 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?
Well, the initscripts package in Ubuntu does provide one script that's run
in /etc/rcS.d (urandom) and several other scripts that are run in other
runlevels (some in 0/6; some in 1; some in 2 3 4 5). But there's definitely
a delta in the initscripts package when used with sysvinit vs. upstart. I'm
not sure if this is something that needs to be specified in policy though,
as opposed to just being worked through in the implementation.
> 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.
I think this is covered already by requiring alternative init
implementations to support running sysvinit scripts - rcS.d is definitely
part of this, just as rc[0-6].d are. Do you think we should be more
explicit about the supported runlevels? (It's awkward to talk about
rc[0-6].d directly, precisely because this is an internal detail of sysv-rc
vs. file-rc)
> > + <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?
I don't believe any alternatives use the same job files today.
Yes, /etc/init is a generic name. /etc/init.d is also. I realize this
smacks of arrogance to put upstart on an equal footing with an init system
that's been established for 20+ years, but frankly, the Unix namespace has
always been first-come, first-serve, and when upstart adopted this
convention there were no credible alternatives competing for the namespace
anyway. And although I've seen systemd proponents complain about this
namespace pollution, it doesn't seem to be due to any desire that systemd
*itself* use it, so there's not really a conflict.
In any event, my intent here is to document the behavior required for
interoperability, and this documents the behavior required for
interoperability with the existing upstart package. If you think upstart
shouldn't use this directory path, please take it up with the upstart
maintainer. :)
> 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?
with current upstart:
$ telinit --version
telinit (upstart 0.6.6)
Copyright (C) 2010 Canonical Ltd.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$
> 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?
Yep!
> And it should just return 0?
I think it needs to return non-zero for purposes of robustness - otherwise
the init script will give false-positives to callers that expect the init
script to be useful when it isn't.
> I wonder if it would be useful to call invoke-rc.d instead
> in that case if it's run by a user.
Sorry, I don't follow this, can you elaborate?
> > + </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.)
9.3.3.2 is about "running init scripts". The above paragraph is about using
the same interface for starting jobs that are *not* init scripts. So I
think this needs to be covered in both places.
> 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.
I think this is orthogonal to the present bug, though. Do you agree?
> 9.3.3.1. could use a re-write as it also seems to be sysvinit
> specific.
Again, IMHO we should keep separate sections for init scripts, which are
defined to be supported everywhere, and init-system-specific requirements.
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
Attachment:
signature.asc
Description: Digital signature