Bug#591791: systemd point of view

[Russ Allbery <rra@debian.org>]

Hi Steve, Tollef,

I've reviewed the latest patch from Steve on this thread and my personal
feeling is that it's about at a place where I'd second it.  There are just
a few things remaining that I think should be addressed, related to what
the migration looks like.

Tollef Fog Heen <tfheen@err.no> writes:

> The patch seems mostly ok to me.  I think we should decide whether we
> want a single invoke-rc.d that everybody uses and which knows how to
> handle all of sysvinit, upstart and systemd or if we want each init
> system to ship their own.  From the patch, it looks like each init
> system should ship their own, but that it still must keep compatibility
> with all other implementations.

I agree that this should be spelled out, since the behavior of invoke-rc.d
is rather important in this proposal.  Currently, it says:

    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.

in the upstart section, which implies *all* implementations of
invoke-rc.d, including the one that comes with sysvinit.  Was the
intention that this would only apply to the one that comes with upstart
itself?

Also:

    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.

This is optional, but I'd still like to get review of this part from the
insserv maintainers.  (Did that happen somewhere earlier in this thread
already?)

Don't we need to say something about how alternative boot managers should
arrange to take over init, given that sysvinit is Essential, so that we
don't break things while doing so?

Finally, given the recommendation:

    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.

I'd really like to see Policy provide some sample code for how to do that,
since otherwise people are going to get this wrong.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>