[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#591791: extend init.d policy to permit upstart jobs and describe their use

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

> +          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  (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. could use a re-write as it also seems to be sysvinit


Reply to: