Bug#591791: extend init.d policy to permit upstart jobs and describe their use
On Wed, Jan 12, 2011 at 12:50:21AM -0600, Steve Langasek wrote:
> 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:
> > > + 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.
I'm fine with leaving it up to the implementation on exactly which
part it does itself and which it takes from initscripts or
somewhere else. But what I do expect is that in the end the system
is in the same state, and I guess I sometimes think too much about
the details of how this is supposed to happen. Does Ubuntu just
ship a package with less scripts in initscripts, or does upstart
lists somewhere which ones it wants or doesn't want?
> > 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)
So you're saying that rcS.d and rc[0-6].d will keep existing? I assumed
it wouldn't exist anymore, or atleast not for all cases, and that
update-rc.d would do something with it that's specific to the init
system.
> > > + <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.
[...]
> 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.
Shouldn't that be part of the upstart documentation in that case
instead of policy?
> > 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.
[...]
> > 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.
Which callers do you have in mind? Shouldn't they be using
invoke-rc.d instead?
> > 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?
I was thinking about cases who calls the /etc/init.d/ scripts,
and only thought of:
- The init system
- invoke-rc.d
- A user (that doesn't know that upstart is being used)
And the rest should be using invoke-rc.d. invoke-rc.d
shouldn't call that script if a job exists for it. For
the user it would be handy that it called invoke-rc.d instead,
or atleast give a message it should't be called directly.
But maybe some 3rd party applications might also be calling
it directly.
> > 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?
I'm not sure yet.
Kurt
Reply to: