Debian Bug report logs - #591791
extend init.d policy to permit upstart jobs and describe their use

version graph

Package: debian-policy; Maintainer for debian-policy is Debian Policy List <debian-policy@lists.debian.org>; Source for debian-policy is src:debian-policy.

Reported by: Steve Langasek <vorlon@debian.org>

Date: Thu, 5 Aug 2010 16:00:01 UTC

Severity: wishlist

Fixed in version debian-policy/3.9.4.0

Done: Russ Allbery <rra@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Thu, 05 Aug 2010 16:00:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
New Bug report received and forwarded. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 05 Aug 2010 16:00:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: submit@bugs.debian.org
Subject: extend init.d policy to permit upstart jobs and describe their use
Date: Thu, 5 Aug 2010 11:57:16 -0400
[Message part 1 (text/plain, inline)]
Package: debian-policy
Severity: wishlist

An action item from the upstart BoF today at DebConf is that policy language
needs to be written around upstart jobs before we can start inflicting them
on the archive.  The following points should be addressed; they can be split
into separate bug reports in the future if needed.

 - packages may ship upstart jobs under /etc/init
 - with limited exceptions (e.g., upstart itself!), a package that ships an
   upstart job must also ship a sysvinit init.d script that implements the
   same functionality
 - packages must use invoke-rc.d in maintainer scripts for either upstart
   jobs or init scripts (but invoke-rc.d must be modified first to support
   this)

Patch to follow later :)

-- 
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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 10 Jan 2011 03:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 10 Jan 2011 03:42:03 GMT) Full text and rfc822 format available.

Message #10 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: 591791@bugs.debian.org
Cc: Scott James Remnant <scott@netsplit.com>, Michael Biebl <biebl@debian.org>, Petter Reinholdtsen <pere@hungry.com>, James Hunt <james.hunt@canonical.com>
Subject: Re: extend init.d policy to permit upstart jobs and describe their use
Date: Sun, 9 Jan 2011 20:10:04 -0600
[Message part 1 (text/plain, inline)]
tags 591791 patch
thanks

Hi there,

Attached is a tentative patch for this bug that documents what I think the
requirements are both for alternative init systems in general, and for
upstart in particular.  Sorry this has taken so long; I spun my wheels on it
for some time because I couldn't quite accept that there were so few
additional requirements that needed to be specified here!  I still don't
entirely believe it, so please let me know if you see anything that I've
overlooked. :)

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.

Cheers,
-- 
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
[0001-Document-generic-and-upstart-specific-init-system-re.patch (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, inline)]

Added tag(s) patch. Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Mon, 10 Jan 2011 03:42:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 10 Jan 2011 20:21:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 10 Jan 2011 20:21:06 GMT) Full text and rfc822 format available.

Message #17 received at 591791@bugs.debian.org (full text, mbox):

From: Kurt Roeckx <kurt@roeckx.be>
To: Steve Langasek <vorlon@debian.org>
Cc: 591791@bugs.debian.org, Scott James Remnant <scott@netsplit.com>, Michael Biebl <biebl@debian.org>, Petter Reinholdtsen <pere@hungry.com>, James Hunt <james.hunt@canonical.com>
Subject: Re: Bug#591791: extend init.d policy to permit upstart jobs and describe their use
Date: Mon, 10 Jan 2011 21:17:33 +0100
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





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 10 Jan 2011 22:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Scott James Remnant <scott@netsplit.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 10 Jan 2011 22:15:03 GMT) Full text and rfc822 format available.

Message #22 received at 591791@bugs.debian.org (full text, mbox):

From: Scott James Remnant <scott@netsplit.com>
To: Kurt Roeckx <kurt@roeckx.be>
Cc: Steve Langasek <vorlon@debian.org>, 591791@bugs.debian.org, Michael Biebl <biebl@debian.org>, Petter Reinholdtsen <pere@hungry.com>, James Hunt <james.hunt@canonical.com>
Subject: Re: Bug#591791: extend init.d policy to permit upstart jobs and describe their use
Date: Mon, 10 Jan 2011 22:12:43 +0000
On Mon, Jan 10, 2011 at 8:17 PM, Kurt Roeckx <kurt@roeckx.be> 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, in the systemd case, all the things those scripts used to do are
built in and hardcoded in systemd itself.  And in the Upstart case,
there is a separate implementation of those as well.

So yes, I think an init system should deal with "core" boot by itself,
as sysvinit does with the initscripts package.

I guess this means policy needs to specify what needs to be done ;-)

(otherwise people may find they get a shock if systemd's hardcoded
mounting doesn't match what they expected)

Scott




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Wed, 12 Jan 2011 06:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 12 Jan 2011 06:54:03 GMT) Full text and rfc822 format available.

Message #27 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Kurt Roeckx <kurt@roeckx.be>
Cc: 591791@bugs.debian.org, Scott James Remnant <scott@netsplit.com>, Michael Biebl <biebl@debian.org>, Petter Reinholdtsen <pere@hungry.com>, James Hunt <james.hunt@canonical.com>
Subject: Re: Bug#591791: extend init.d policy to permit upstart jobs and describe their use
Date: Wed, 12 Jan 2011 00:50:21 -0600
[Message part 1 (text/plain, inline)]
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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Wed, 12 Jan 2011 18:42:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 12 Jan 2011 18:42:06 GMT) Full text and rfc822 format available.

Message #32 received at 591791@bugs.debian.org (full text, mbox):

From: Kurt Roeckx <kurt@roeckx.be>
To: Steve Langasek <vorlon@debian.org>
Cc: 591791@bugs.debian.org, Scott James Remnant <scott@netsplit.com>, Michael Biebl <biebl@debian.org>, Petter Reinholdtsen <pere@hungry.com>, James Hunt <james.hunt@canonical.com>
Subject: Re: Bug#591791: extend init.d policy to permit upstart jobs and describe their use
Date: Wed, 12 Jan 2011 19:38:05 +0100
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





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Wed, 12 Jan 2011 23:51:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Scott James Remnant <scott@netsplit.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 12 Jan 2011 23:51:07 GMT) Full text and rfc822 format available.

Message #37 received at 591791@bugs.debian.org (full text, mbox):

From: Scott James Remnant <scott@netsplit.com>
To: Kurt Roeckx <kurt@roeckx.be>
Cc: Steve Langasek <vorlon@debian.org>, 591791@bugs.debian.org, Michael Biebl <biebl@debian.org>, Petter Reinholdtsen <pere@hungry.com>, James Hunt <james.hunt@canonical.com>
Subject: Re: Bug#591791: extend init.d policy to permit upstart jobs and describe their use
Date: Wed, 12 Jan 2011 23:48:20 +0000
On Wed, Jan 12, 2011 at 6:38 PM, Kurt Roeckx <kurt@roeckx.be> wrote:
> 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:
>> > 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?
>
The Ubuntu initscripts package contains fewer and modified scripts
(the plan is for it to not exist at all), since the conversion has
been made for those tasks to be performed by Upstart jobs.

(Systemd largely has support for those tasks built-in)

>> > 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.
>
I would have thought that rcS.d/rc[0-6].d are not compulsory parts, as
replacement init systems may simply read the LSB headers from the top
and allow them to be overridden in some way.

To me, the update-rc.d/chkconfig style standard is the right one.

Scott




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Sat, 15 Jan 2011 21:48:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 15 Jan 2011 21:48:08 GMT) Full text and rfc822 format available.

Message #42 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Kurt Roeckx <kurt@roeckx.be>
Cc: 591791@bugs.debian.org, Scott James Remnant <scott@netsplit.com>, Michael Biebl <biebl@debian.org>, Petter Reinholdtsen <pere@hungry.com>, James Hunt <james.hunt@canonical.com>
Subject: Re: Bug#591791: extend init.d policy to permit upstart jobs and describe their use
Date: Sat, 15 Jan 2011 14:25:00 -0600
[Message part 1 (text/plain, inline)]
On Wed, Jan 12, 2011 at 07:38:05PM +0100, Kurt Roeckx wrote:
> 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:

> > > 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.

I'm saying that SysV *runlevels* will continue to exist.  Whether or not the
rc{S,0-6}.d *directories* continue to exist is an implementation detail for
update-rc.d to sort through (and we already have update-rc.d implementations
in the archive that don't use these symlinks), but init systems and packages
must still continue to be able to interface with each other this way
(packages by declaring when their scripts should be run with start/stop
arguments; init systems by running those scripts at the appropriate time).

> > > /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?

There are over 100 upstart jobs (not including those in the upstart package
itself) in Ubuntu today, and I fully expect these to flood into Debian once
the gates are opened.  This is not a matter of a small number of packages
coming up with a private interface for interoperation; it's going to have a
broad impact, and that's the sort of thing we document in Policy.

If you think that upstart should be *mandated* to use a different directory
instead of /etc/init, then Policy is the place to do that, too; I just can't
see any justification for such an override.

> > > 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?

invoke-rc.d is an interface for maintainer scripts.  Admins are known to
call init scripts directly; cluster management tools may do likewise, though
it's also possible these will use invoke-rc.d instead.

If nothing else, an init script that returns success on 'start' without
starting the service would be inconsistent with how we've expected all init
scripts to work to date.  (It's not *quite* a policy violation, but near
enough to.)  And if you argue that nothing should ever call these init
scripts because everything should use invoke-rc.d, then things using this
upstart-aware interface will never see the return code anyway, right?

> > > 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.

No, definitely not.  It's important that admins have the capability of
manually starting services out of runlevel, and for this the (historical)
interface is to invoke the init script directly.  (Nowadays, I would argue
that these admins should use the 'service' command instead, for which
upstart-aware patches already exist.  However, the 'service' interface is a
relatively recent addition to Debian, and I expect many admins are still
invoking init scripts directly.)

Cheers,
-- 
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
[signature.asc (application/pgp-signature, inline)]

Added indication that bug 591791 blocks 577040 Request was from Steve Langasek <steve.langasek@canonical.com> to control@bugs.debian.org. (Mon, 17 Jan 2011 05:51:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 04 Feb 2011 21:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tollef Fog Heen <tfheen@err.no>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 04 Feb 2011 21:15:03 GMT) Full text and rfc822 format available.

Message #49 received at 591791@bugs.debian.org (full text, mbox):

From: Tollef Fog Heen <tfheen@err.no>
To: 591791@bugs.debian.org
Subject: systemd point of view
Date: Fri, 04 Feb 2011 22:11:40 +0100
Hi,

Steve, first I'd like to thank you for bootstrapping this discussion and
proposing the policy text.  It's a good start.

I thought I should chime in about what I envision for systemd in Debian
so we can make sure we end up with no conflicts between upstart's and
systemd's implementations in Debian.  I haven't subscribed to the bug
report from the start, so I'll try to summarise and copy and paste from
various replies in the bug.

]] Kurt Roeckx

| 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?

systemd blacklists some of them, but run the rest as normal init scripts
that are needed before we reach sysinit.target, then the normal runlevel
scripts are run.

| /etc/init seems to be a very general directory name for an upstart
| job. Can the alternatives use the same job files as upstart?

systemd can't, at least.  We use /etc/systemd so while I dislike the
namespace grab of upstart, it won't cause any problems for systemd.

(It also breaks tab completion for those of us who like to run init
scripts by hand, which is going to affect everybody, but initramfs-tools
already did that so that damage is done already.)

From the proposed policy patch:

+  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.

My system actually already has upstart installed, but doesn't use it, so
upstart's telinit will have to be fixed to not report «upstart» in its
version string if the running init is not upstart.  That's slightly
orthogonal to this bug report, but it shows that you can't necessarily
depend on the output of --version and such to know what's running.  This
will also affect people on migration from one init system to another.

+            Dependency-based boot managers for SysV init scripts, such as
+            <package>insserv</package>, may bypass a given init script
+            entirely when an equivalent upstart job is present, to avoid
+            unnecessary forking of no-op init scripts. 

What happens to the dependency resolution of insserv in that case?  I'd
much rather have insserv not do anything and the non-sysvinit init
system be smart and parse LSB headers rather than insserv seeing that A
depends B, but B is missing (since it's provided by a systemd
service/upstart job) and then flake out.

I'd also like us to forbid depending on implementation-specific scripts
such as mountkernfs since there won't necessarily be anything that maps
to in a non-sysvinit world.  The exception would be if an init script is
shipped as part of the init system, so sysv-rc's scripts could have
dependencies on mountkernfs, but random daemons could not.

A final thing I'd like to get added to the policy text is how
standardised facility names are handled.  insserv for some reason does
not handle init scripts providing $x-display-manager and similar, but
requires those to be added to the insserv configuration file.  We should
either require init implementations to allow providing the standardised
facility names or we should put that information somewhere in a a
neutral location and format so all init implementations can make use of
it.

Best regards,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 14 Feb 2011 10:48:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Marco Amadori <amadorim@vdavda.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 14 Feb 2011 10:48:07 GMT) Full text and rfc822 format available.

Message #54 received at 591791@bugs.debian.org (full text, mbox):

From: Marco Amadori <amadorim@vdavda.com>
To: Joachim Breitner <nomeata@debian.org>
Cc: "Debian FreeSmartphone.Org Team" <pkg-fso-maint@lists.alioth.debian.org>, Enrico Zini <enrico@debian.org>, 602511@bugs.debian.org, 591791@bugs.debian.org, debian-devel@lists.debian.org, marco.amadori@gmail.com
Subject: Upstart and sysvinit in packages - Policy needed
Date: Mon, 14 Feb 2011 11:17:20 +0100
[Message part 1 (text/plain, inline)]
In data Saturday 12 February 2011 05:55:16, Joachim Breitner ha scritto:

>> I included some patches to have nodm gracefully uses the upstart job.

>> Since those patches permits to have both init scripts in the system, no
>> matter if upstart or sysvinit is used, a little more effort is required
>> to proper build this package.
 
> thanks for your patches. I applied them to the repo besides the patch
> 0005-Exit-from-the-sysvinit-script-to-use-the-upstart-job.patch. Is that
> code taken from some existing package?

I took the idea from discussion on bug #591791 and updated to work also with 
current sysvinit, that does currently not likes the syntax "--version".

I include again this patch to permits other people to follow the discussion 
there, but is just a matter of :

if [ -e "/etc/init/${NAME}.conf" ] && /sbin/telinit --version >/dev/null 2>&1 
| grep -qs upstart
then
	exit 0
fi

inside the sysvinit init script.

> I feel like the semantics of both
> upstart jobs and init scripts in one package should be the same across
> packages, so I’d rather see a common solution for that.

Yes, probably something better and simpler than my lines above should emerge 
from the discussion.

>> But I'm stuck as you are (in the git repo) because dh will refuse to add
>> an init.d script if an upstart job is available.
>> Any hints on how to neatly have both init script files on the binary
>> package?

> Maybe you could raise the issue on d-devel?

I CCed the bug in the policy that seems to be the best match for the 
discussion, anyway I'll CC also d-devel to have some help.

Even if all agrees that my code above is right (a thing that I cannot imagine 
to be true in any universe), if it vital that a policy is given for that 
issue.

I think it would be interesting for wheezy to easely permit an Admin to choose 
an alternate init system and to permit to package maintainer to carefully 
provide init script tailored for a particular system of interest.

Debhelper seems to not permit to have both, e.g., an upstart and a sysvinit 
script available in the package, although with a trick like the above 
mentioned one, the could happily live together in perfect armony, side by side 
on my wheezy.

-- 
ESC:wq

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[0005-Exit-from-the-sysvinit-script-to-use-the-upstart-job.patch (text/x-patch, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 14 Feb 2011 18:09:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 14 Feb 2011 18:09:06 GMT) Full text and rfc822 format available.

Message #59 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Marco Amadori <amadorim@vdavda.com>, 591791@bugs.debian.org
Cc: Joachim Breitner <nomeata@debian.org>, "Debian FreeSmartphone.Org Team" <pkg-fso-maint@lists.alioth.debian.org>, Enrico Zini <enrico@debian.org>, 602511@bugs.debian.org, debian-devel@lists.debian.org, marco.amadori@gmail.com
Subject: Re: Bug#591791: Upstart and sysvinit in packages - Policy needed
Date: Mon, 14 Feb 2011 10:06:45 -0800
On Mon, Feb 14, 2011 at 11:17:20AM +0100, Marco Amadori wrote:
> In data Saturday 12 February 2011 05:55:16, Joachim Breitner ha scritto:

> >> I included some patches to have nodm gracefully uses the upstart job.

> >> Since those patches permits to have both init scripts in the system, no
> >> matter if upstart or sysvinit is used, a little more effort is required
> >> to proper build this package.

> > thanks for your patches. I applied them to the repo besides the patch
> > 0005-Exit-from-the-sysvinit-script-to-use-the-upstart-job.patch. Is that
> > code taken from some existing package?

> I took the idea from discussion on bug #591791 and updated to work also with 
> current sysvinit, that does currently not likes the syntax "--version".

> I include again this patch to permits other people to follow the discussion 
> there, but is just a matter of :

> if [ -e "/etc/init/${NAME}.conf" ] && /sbin/telinit --version >/dev/null 2>&1 
> | grep -qs upstart
> then
> 	exit 0
> fi

> inside the sysvinit init script.

This does not appear to be consistent with
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591791#42, in particular:

  If nothing else, an init script that returns success on 'start' without
  starting the service would be inconsistent with how we've expected all
  init scripts to work to date.  (It's not *quite* a policy violation, but
  near enough to.) And if you argue that nothing should ever call these init
  scripts because everything should use invoke-rc.d, then things using this
  upstart-aware interface will never see the return code anyway, right?

Oh, and if you redirect telinit stdout and stderr both to /dev/null, that
grep is always going to return false.


Also, I strongly counsel *against* shipping this, or any, upstart job in a
Debian package until this policy bug is *fixed*.  The conversation is
ongoing, and deploying such upstart jobs now realistically just runs the
(very high) risk that you'll have more work to do on your package later once
the policy interfaces are refined and implemented.


BTW, my goal is to provide this functionality in an lsb-style function; that
will preclude both the call to 'exit' here (with any return value) or
checking for ${NAME} in the code; anyway, a package should darn well know
whether it's set up to ship both an upstart job and an init script and not
need to query the filesystem to figure that out.


> Debhelper seems to not permit to have both, e.g., an upstart and a sysvinit 
> script available in the package, although with a trick like the above 
> mentioned one, the could happily live together in perfect armony, side by side 
> on my wheezy.

Debhelper doesn't permit both because policy does not specify how this is
supposed to work.  I have already submitted a patch to debhelper (bug
#577040), which I have asked Joey to sit on until policy is finalized and
various other key packages have implemented the necessary support (namely,
sysvinit and lsb-base).

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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 14 Feb 2011 20:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Marco Amadori <marco.amadori@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 14 Feb 2011 20:18:03 GMT) Full text and rfc822 format available.

Message #64 received at 591791@bugs.debian.org (full text, mbox):

From: Marco Amadori <marco.amadori@gmail.com>
To: Steve Langasek <vorlon@debian.org>
Cc: Marco Amadori <amadorim@vdavda.com>, 591791@bugs.debian.org, Joachim Breitner <nomeata@debian.org>, "Debian FreeSmartphone.Org Team" <pkg-fso-maint@lists.alioth.debian.org>, Enrico Zini <enrico@debian.org>, 602511@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#591791: Upstart and sysvinit in packages - Policy needed
Date: Mon, 14 Feb 2011 21:14:44 +0100
On Monday 14 February 2011 21:07:57 Steve Langasek wrote:

> > if [ -e "/etc/init/${NAME}.conf" ] && /sbin/telinit --version >/dev/null
> > 2>&1
> > | grep -qs upstart
> > then
> > 	exit 0
> > fi
> > 
> > inside the sysvinit init script.
> 
> This does not appear to be consistent with
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591791#42, in particular:
> 
>   If nothing else, an init script that returns success on 'start' without
>   starting the service would be inconsistent with how we've expected all
>   init scripts to work to date.  (It's not *quite* a policy violation, but
>   near enough to.) And if you argue that nothing should ever call these
> init scripts because everything should use invoke-rc.d, then things using
> this upstart-aware interface will never see the return code anyway, right?

I'm so sorry, in the hurry I put an exit 0 for the wrong psycological reasons, 
you are right.

> Oh, and if you redirect telinit stdout and stderr both to /dev/null, that
> grep is always going to return false.

This is a bad mistake for sure! I apologize to all for being so naïve and 
publishing a bad tested code (I tested an uncommitted previous release, then I 
"improved" and submitted without tests!!)

Again, I apologize.

> Also, I strongly counsel *against* shipping this, or any, upstart job in a
> Debian package until this policy bug is *fixed*.

This seems a good point, having that debhelper prefer upstart jobs over 
sysvinit when both are available.

> > Debhelper seems to not permit to have both, e.g., an upstart and a
> > sysvinit script available in the package, although with a trick like the
> > above mentioned one, the could happily live together in perfect armony,
> > side by side on my wheezy.
 
> Debhelper doesn't permit both because policy does not specify how this is
> supposed to work.  I have already submitted a patch to debhelper (bug
> #577040), which I have asked Joey to sit on until policy is finalized and
> various other key packages have implemented the necessary support (namely,
> sysvinit and lsb-base).

I hope that this discussion could help in clarifing this matter, probably the 
times are mature enough.

-- 
ESC:wq




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Sat, 05 Mar 2011 08:21:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 05 Mar 2011 08:21:06 GMT) Full text and rfc822 format available.

Message #69 received at 591791@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Steve Langasek <vorlon@debian.org>
Cc: 591791@bugs.debian.org, Scott James Remnant <scott@netsplit.com>, Michael Biebl <biebl@debian.org>, Petter Reinholdtsen <pere@hungry.com>, James Hunt <james.hunt@canonical.com>
Subject: Re: extend init.d policy to permit upstart jobs and describe their use
Date: Sat, 5 Mar 2011 02:19:12 -0600
Hi,

Steve Langasek wrote:

> Sorry this has taken so long; I spun my wheels on it
> for some time because I couldn't quite accept that there were so few
> additional requirements that needed to be specified here!

Thanks for your work. :)

[...]
> +          tasks at boot time.  However, any package integrating with other
> +          init systems must also be backwards-compatible with
> +          <package>sysvinit</package> by providing a SysV-style init script
> +          with the same name as and equivalent functionality to any
> +          init-specific job, as this is the only start-up configuration
> +          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.

Maybe policy could allow (but discourage) packages that only support
some non-Sys-V init system as long as they include a dependency
indicating so?

One of the advantages of upstart and its kin is the simpler
configuration, after all, so I can imagine some maintainers wanting to
take advantage of that and not having time to debug a standard init
script.  The example that led me to mention this is Bug#422139; it is
not quite the same issue but is related.

> +                                               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>

As Tollef mentioned, upstart can be installed without being init.

This currently spews a usage string to stderr on sysvinit.  I wonder
if there is some other way to ask init whether it is upstart?  As a
naïve user, I'd prefer the SysV init scripts to pass on requests to
upstart when upstart is running; is that feasible?

I suspect it would be best to make the language init system neutral,
and to say something to this effect:

. sysvinit scripts need to behave reasonably regardless of the init
  system in use.  So:

 i. If an equivalent job file for another init system is present, the
    sysvinit script will not be automatically invoked by that init
    system when switching runlevels.  In this case, when that init
    system is in use, the sysvinit script (if invoked by hand, for
    example) must either delegate requests to the init system or
    error out without doing anything.  Don't fight with init(8).

ii. Even if an equivalent job file for another init system is
    available, the sysvinit script should behave as advertised (and
    not be a no-op) when init is sysvinit.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Sat, 05 Mar 2011 13:33:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 05 Mar 2011 13:33:06 GMT) Full text and rfc822 format available.

Message #74 received at 591791@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Jonathan Nieder <jrnieder@gmail.com>, 591791@bugs.debian.org
Cc: Steve Langasek <vorlon@debian.org>, Scott James Remnant <scott@netsplit.com>, Michael Biebl <biebl@debian.org>, Petter Reinholdtsen <pere@hungry.com>, James Hunt <james.hunt@canonical.com>
Subject: Re: Bug#591791: extend init.d policy to permit upstart jobs and describe their use
Date: Sat, 5 Mar 2011 14:29:05 +0100
On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote:
> Hi,
> 
> Steve Langasek wrote:
> 
> > Sorry this has taken so long; I spun my wheels on it
> > for some time because I couldn't quite accept that there were so few
> > additional requirements that needed to be specified here!
> 
> Thanks for your work. :)
> 
> [...]
> > +          tasks at boot time.  However, any package integrating with other
> > +          init systems must also be backwards-compatible with
> > +          <package>sysvinit</package> by providing a SysV-style init script
> > +          with the same name as and equivalent functionality to any
> > +          init-specific job, as this is the only start-up configuration
> > +          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.
> 
> Maybe policy could allow (but discourage) packages that only support
> some non-Sys-V init system as long as they include a dependency
> indicating so?

This would be a terrible idea. We would end up with packages that will not
be work together because they depend on different init systems.

> One of the advantages of upstart and its kin is the simpler
> configuration, after all, so I can imagine some maintainers wanting to
> take advantage of that and not having time to debug a standard init
> script.  The example that led me to mention this is Bug#422139; it is
> not quite the same issue but is related.

The whole point of Debian policy is to promote interoperability, not to allow
maintainer to make quick-and dirty packages.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Sat, 05 Mar 2011 13:36:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 05 Mar 2011 13:36:06 GMT) Full text and rfc822 format available.

Message #79 received at 591791@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
Cc: 591791@bugs.debian.org, Steve Langasek <vorlon@debian.org>, Scott James Remnant <scott@netsplit.com>, Michael Biebl <biebl@debian.org>, Petter Reinholdtsen <pere@hungry.com>, James Hunt <james.hunt@canonical.com>
Subject: Re: extend init.d policy to permit upstart jobs and describe their use
Date: Sat, 5 Mar 2011 07:32:14 -0600
Bill Allombert wrote:
> On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote:

>> Maybe policy could allow (but discourage) packages that only support
>> some non-Sys-V init system as long as they include a dependency
>> indicating so?
>
> This would be a terrible idea. We would end up with packages that will not
> be work together because they depend on different init systems.

Very good point.  Sorry, I wasn't thinking straight.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 21 Mar 2011 10:33:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 21 Mar 2011 10:33:06 GMT) Full text and rfc822 format available.

Message #84 received at 591791@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: 619093@bugs.debian.org
Cc: Chris Lawrence <lawrencc@debian.org>, 591791@bugs.debian.org, Steve Langasek <vorlon@debian.org>
Subject: Re: Bug#619093: splashy and systemd: error when trying to install together
Date: Mon, 21 Mar 2011 11:30:06 +0100
[Message part 1 (text/plain, inline)]
Am 21.03.2011 10:56, schrieb Michael Biebl:
> Am 21.03.2011 08:07, schrieb Ralf Treinen:
> 
>> Here is a list of files that are known to be shared by both packages
>> (according to the Contents file for sid/amd64, which may be
>> slightly out of sync):
>>
>>   /etc/lsb-base-logging.sh
> 
> The two packages don't share any kind of functionality in
> /etc/lsb-base-logging.sh, so an alternatives approach or a simple Replaces won't
> work.
> 
> splashy uses it to overwrite the logging calls, systemd to redirect the complete
> script to systemd, i.e. a call to
> /etc/init.d/<foo> <action>
> translates into
> systemctl <action> <foo.service>
> 
> One might argue, that /etc/lsb-base-logging.sh is not the best place for that,
> and I wouldn't disagree. Unfortunately there is afaik currently no better place
> to hook into the lsb init functions library.
> 
> So I guess it's best if we move the systemd bits directly into lsb-base itself
> and use a Conflicts against splashy until this is done.
> 
> Chris, would you be ok with shipping the functionality of the systemd lsb init
> hook [1] in lsb-base (/lib/lsb/init-functions) itself?
> 
> 
> [1]
> http://git.err.no/cgi-bin/gitweb.cgi?p=systemd;a=blob;f=debian/lsb-base-logging.sh;h=2998bdbb37df219e73e149b4b45ee400a9870a30;hb=refs/heads/debian

I think this also affects #591791, so I CCed Steve and the debian-policy bug.

Our original idea for upstart and sysv compatibility was, that packages shipping
native upstart jobs would ship a symlink from
/etc/init.d/foo → /lib/init/upstart-job, which translates it to initctl/upstart
calls.

This approach works, if you can rely on upstart being installed, which on
Debian, especially on kfreebsd is not the case, so this idea never really took of.

So, in #591791 Steve proposed that packages should continue to ship sysv init
script, regardless if they have a native upstart job or not, and I basically
agree with that.
What I don't like about the proposal in #591791 is, that each sysv init script
should check itself, if it is run under upstart and exit.

This means we duplicate a lot of code and add upstart specific interna to every
init script shipping a native upstart job.

I'd much prefer if we could use the /lib/lsb/init-functions lib to do the same
kind of redirecting for upstart. That is, all a package needs to do if it ships
a native upstart job (or systemd service), is to include .
/lib/lsb/init-functions in its sysv init script.
/lib/lsb/init-functions would then do the correct thing, when it is run under
systemd or upstart.

Steve, do you think this would be an approach that works for upstart (and Ubuntu)?

Michael





-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 21 Mar 2011 18:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 21 Mar 2011 18:00:03 GMT) Full text and rfc822 format available.

Message #89 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Michael Biebl <biebl@debian.org>, 591791@bugs.debian.org
Cc: 619093@bugs.debian.org, Chris Lawrence <lawrencc@debian.org>
Subject: Re: Bug#591791: Bug#619093: splashy and systemd: error when trying to install together
Date: Mon, 21 Mar 2011 10:58:23 -0700
[Message part 1 (text/plain, inline)]
Hi Michael,

On Mon, Mar 21, 2011 at 11:30:06AM +0100, Michael Biebl wrote:

> So, in #591791 Steve proposed that packages should continue to ship sysv
> init script, regardless if they have a native upstart job or not, and I
> basically agree with that.

> What I don't like about the proposal in #591791 is, that each sysv init
> script should check itself, if it is run under upstart and exit.

> This means we duplicate a lot of code and add upstart specific interna to
> every init script shipping a native upstart job.

Right, in the policy proposal I am describing that each init script is
responsible for checking this.  But the actual *implementation* of this
check can and should use a common shell library to do the heavy lifting.
Sorry, I didn't think that specifying that belonged in policy.  Do you think
the use of a common shell library should be enforced in policy as part of
this?

> I'd much prefer if we could use the /lib/lsb/init-functions lib to do the
> same kind of redirecting for upstart.  That is, all a package needs to do
> if it ships a native upstart job (or systemd service), is to include .
> /lib/lsb/init-functions in its sysv init script.  lib/lsb/init-functions
> /would then do the correct thing, when it is run under
> systemd or upstart.

> Steve, do you think this would be an approach that works for upstart (and
> Ubuntu)?

I hadn't thought about having /lib/lsb/init-functions automatically do this
checking when sourced.  I think on some level the idea offends me, the same
way having C libraries call setuid() or exit() offends me. :)  Also, this
check is only needed for those packages that *ship* an upstart job, and
surely those packages know who they are and can handle the conversion easily
enough if we give them a function to call?

-- 
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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 21 Mar 2011 18:33:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 21 Mar 2011 18:33:03 GMT) Full text and rfc822 format available.

Message #94 received at 591791@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Steve Langasek <vorlon@debian.org>, 591791@bugs.debian.org
Cc: 619093@bugs.debian.org, Chris Lawrence <lawrencc@debian.org>
Subject: Re: Bug#591791: Bug#619093: splashy and systemd: error when trying to install together
Date: Mon, 21 Mar 2011 19:30:55 +0100
[Message part 1 (text/plain, inline)]
Hi Steve!

Am 21.03.2011 18:58, schrieb Steve Langasek:
> On Mon, Mar 21, 2011 at 11:30:06AM +0100, Michael Biebl wrote:

> 
> Right, in the policy proposal I am describing that each init script is
> responsible for checking this.  But the actual *implementation* of this
> check can and should use a common shell library to do the heavy lifting.
> Sorry, I didn't think that specifying that belonged in policy.  Do you think
> the use of a common shell library should be enforced in policy as part of
> this?

I do think it would make sense to agree on the name of such a shell library and
at least mention and recommend it in the policy text.
My concern is that if we don't encourage a common shell lib we get all sorts of
inconsistencies and if we need to make adjustments later on (return codes etc)
it's much easier to do it in one place.


>> I'd much prefer if we could use the /lib/lsb/init-functions lib to do the
>> same kind of redirecting for upstart.  That is, all a package needs to do
>> if it ships a native upstart job (or systemd service), is to include .
>> /lib/lsb/init-functions in its sysv init script.  lib/lsb/init-functions
>> /would then do the correct thing, when it is run under
>> systemd or upstart.
> 
>> Steve, do you think this would be an approach that works for upstart (and
>> Ubuntu)?
> 
> I hadn't thought about having /lib/lsb/init-functions automatically do this
> checking when sourced.  I think on some level the idea offends me, the same
> way having C libraries call setuid() or exit() offends me. :)  Also, this
> check is only needed for those packages that *ship* an upstart job, and
> surely those packages know who they are and can handle the conversion easily
> enough if we give them a function to call?

True. The current version of upstart does not (yet) natively support SysV init
scripts, and relies on /etc/init.d/rc to start those services. SysV services in
upstart don't run under the supervision of upstart.
In systemd the situation is a bit different, as SysV init scripts are basically
just another configuration source and we also want to start SysV services under
the supervision of systemd.
I remember though Scott saying though that "native" SysV support was planned in
upstart. So I'm just thinking ahead a bit.
Using /lib/lsb/init-functions has the huge advantage that we already have a
pretty good coverage of SysV init scripts using it (~70 %), which don't need to
be changed to support this redirection scheme.

For upstart with its current features, the shell lib would only redirect the
call to initctl/upstart if if finds a upstart job with the same name as the SysV
init script and would be a nop otherwise.

Regarding the redirection scheme and your loathing of exit, how would you
envision such an interface should look like?

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Wed, 06 Jul 2011 23:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Enrico Zini <enrico@enricozini.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 06 Jul 2011 23:39:03 GMT) Full text and rfc822 format available.

Message #99 received at 591791@bugs.debian.org (full text, mbox):

From: Enrico Zini <enrico@enricozini.org>
To: Joachim Breitner <nomeata@debian.org>, 602511@bugs.debian.org, Marco Amadori <amadorim@vdavda.com>, 591791@bugs.debian.org, "Debian FreeSmartphone.Org Team" <pkg-fso-maint@lists.alioth.debian.org>, debian-devel@lists.debian.org, marco.amadori@gmail.com
Cc: Luigi Capriotti <l.capriotti@xbmc.org>
Subject: Re: Bug#602511: Fwd: Re: upstart support for nodm
Date: Thu, 7 Jul 2011 01:35:00 +0200
[Message part 1 (text/plain, inline)]
On Tue, Feb 08, 2011 at 11:31:40PM +0530, Joachim Breitner wrote:

> But then I find that dh_installinit would not install the regular init
> script if an upstart job is present, uses a compatibility link
> in /etc/init.d and adds a dependency on upstart-job, which seems to be
> only provided by upstart. I’m not sure if we want to force all users of
> nodm to switch to upstart – or is there an alternative?
> 
> Enrico, what is your level of caring about nodm ATM?

It goes in bursts, mainly depending on when I have customers who would
like me to work on it.

I've just finished a rewrite so that nodm is now a real package manager,
tomorrow I'll do some real world testing and if all goes well, an upload
of the new version to unstable.


On Mon, Feb 14, 2011 at 10:06:45AM -0800, Steve Langasek wrote:

> Also, I strongly counsel *against* shipping this, or any, upstart job in a
> Debian package until this policy bug is *fixed*.  The conversation is
> ongoing, and deploying such upstart jobs now realistically just runs the
> (very high) risk that you'll have more work to do on your package later once
> the policy interfaces are refined and implemented.

That is fine with me, I'll do that.

I must admit that I've just found myself in a rather intense WTF moment,
after finding out that the nodm package from the master branch was
depending on upstart and not shipping an init.d file.

I'm now going to move the upstart work that has been committed (thank
you for it, though!) to a separate "upstart" branch, and I'll upload
without it for now.


Ciao,

Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Thu, 07 Jul 2011 07:48:21 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joachim Breitner <nomeata@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 07 Jul 2011 07:48:23 GMT) Full text and rfc822 format available.

Message #104 received at 591791@bugs.debian.org (full text, mbox):

From: Joachim Breitner <nomeata@debian.org>
To: Enrico Zini <enrico@enricozini.org>
Cc: 602511@bugs.debian.org, Marco Amadori <amadorim@vdavda.com>, 591791@bugs.debian.org, "Debian FreeSmartphone.Org Team" <pkg-fso-maint@lists.alioth.debian.org>, debian-devel@lists.debian.org, marco.amadori@gmail.com, Luigi Capriotti <l.capriotti@xbmc.org>
Subject: Re: Bug#602511: Fwd: Re: upstart support for nodm
Date: Thu, 07 Jul 2011 09:36:38 +0200
[Message part 1 (text/plain, inline)]
Hi,

Am Donnerstag, den 07.07.2011, 01:35 +0200 schrieb Enrico Zini:
> On Tue, Feb 08, 2011 at 11:31:40PM +0530, Joachim Breitner wrote:
> 
> > But then I find that dh_installinit would not install the regular init
> > script if an upstart job is present, uses a compatibility link
> > in /etc/init.d and adds a dependency on upstart-job, which seems to be
> > only provided by upstart. I’m not sure if we want to force all users of
> > nodm to switch to upstart – or is there an alternative?
> > 
> > Enrico, what is your level of caring about nodm ATM?
> 
> It goes in bursts, mainly depending on when I have customers who would
> like me to work on it.
> 
> I've just finished a rewrite so that nodm is now a real package manager,
> tomorrow I'll do some real world testing and if all goes well, an upload
> of the new version to unstable.

Great, I always found nodm a far better approach than dpkg!

(Sorry, CNR ;-))

> On Mon, Feb 14, 2011 at 10:06:45AM -0800, Steve Langasek wrote:
> 
> > Also, I strongly counsel *against* shipping this, or any, upstart job in a
> > Debian package until this policy bug is *fixed*.  The conversation is
> > ongoing, and deploying such upstart jobs now realistically just runs the
> > (very high) risk that you'll have more work to do on your package later once
> > the policy interfaces are refined and implemented.
> 
> That is fine with me, I'll do that.
> 
> I must admit that I've just found myself in a rather intense WTF moment,
> after finding out that the nodm package from the master branch was
> depending on upstart and not shipping an init.d file.
> 
> I'm now going to move the upstart work that has been committed (thank
> you for it, though!) to a separate "upstart" branch, and I'll upload
> without it for now.

Sounds good to me, and thanks for the ongoing maintenance.

BTW, since I stopped using the Freerunner and, after your rewrite (which
I appreciate!), don’t really know any of the nodm code, would you mind
taking over maintenance completely? I doubt that I add much value here
any more.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Thu, 07 Jul 2011 16:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Enrico Zini <enrico@enricozini.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 07 Jul 2011 16:45:03 GMT) Full text and rfc822 format available.

Message #109 received at 591791@bugs.debian.org (full text, mbox):

From: Enrico Zini <enrico@enricozini.org>
To: Joachim Breitner <nomeata@debian.org>
Cc: 602511@bugs.debian.org, Marco Amadori <amadorim@vdavda.com>, 591791@bugs.debian.org, "Debian FreeSmartphone.Org Team" <pkg-fso-maint@lists.alioth.debian.org>, debian-devel@lists.debian.org, marco.amadori@gmail.com, Luigi Capriotti <l.capriotti@xbmc.org>
Subject: Re: Bug#602511: Fwd: Re: upstart support for nodm
Date: Thu, 7 Jul 2011 18:44:22 +0200
[Message part 1 (text/plain, inline)]
On Thu, Jul 07, 2011 at 09:36:38AM +0200, Joachim Breitner wrote:

> BTW, since I stopped using the Freerunner and, after your rewrite (which
> I appreciate!), don’t really know any of the nodm code, would you mind
> taking over maintenance completely? I doubt that I add much value here
> any more.

I rather you studied the new code and gave a hand :P

It's fine, I don't mind taking over maintenance completely, only it's
going to be in bursts as it's been so far, and having at least a
comaintainer who can look after minor packaging issues or simple BTS
interaction would be a good idea. It doesn't have to be you, of course.


Ciao,

Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Sat, 09 Jul 2011 00:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to jidanni@jidanni.org:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 09 Jul 2011 00:33:03 GMT) Full text and rfc822 format available.

Message #114 received at 591791@bugs.debian.org (full text, mbox):

From: jidanni@jidanni.org
To: enrico@enricozini.org, 633089@bugs.debian.org
Cc: nomeata@debian.org, 591791@bugs.debian.org, debian-devel@lists.debian.org, 602511@bugs.debian.org, marco.amadori@gmail.com, l.capriotti@xbmc.org, pkg-fso-maint@lists.alioth.debian.org, amadorim@vdavda.com
Subject: Re: Bug#602511: Fwd: Re: upstart support for nodm
Date: Sat, 09 Jul 2011 08:30:54 +0800
All I know is you fellows broke nodm rather royally for me.
I use nodm on desktops and laptops, with Debian flavor:
deb http://ftp.us.debian.org/debian experimental main contrib non-free
deb http://ftp.us.debian.org/debian unstable main contrib non-free

I did aptitude forbid-version nodm and will stay with
nodm:
  Installed: 0.7-1.1
  Candidate: 0.8-1
for now. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633089
I fear assisting further test will injure my monitors, judging from how
the multitude of different behaviors observed upon start, no matter the
value of NODM_USER, including root and vanilla test accounts.

The old nodm started right away, no ifs ands or buts. On my three
computers, the new one just sputters along, popping in and out of a
blank screen and then back to the console and back to the blank screen.
Or dying completely. Or getting into X but not reading ~/.Xresources ...
etc. Must be some kind of a race condition, that's all I know. Yes, I
purged and reinstalled. Snap, crackle, pop. No more testing for me lest
I need to go to town to buy a new monitor.

P.S., Upon install we are asked "start at boot...?" Well if we say "no",
we will never be able to start it, and the rest of the configuration is
aborted. That message needs to be updated to sysv-rc-conf(8) era
thinking. Giving more details, for the user who still wants
/etc/init.d/nodm start to work, but not to start at boot. (I start via a
question with countdown in /etc/rc.local myself).




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Tue, 18 Oct 2011 04:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 18 Oct 2011 04:33:03 GMT) Full text and rfc822 format available.

Message #119 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Tollef Fog Heen <tfheen@err.no>, 591791@bugs.debian.org
Subject: Re: Bug#591791: systemd point of view
Date: Mon, 17 Oct 2011 21:29:13 -0700
[Message part 1 (text/plain, inline)]
Hi Tollef,

Picking up this policy thread after a bit...  Let's see if we can drive this
to a conclusion now.

On Fri, Feb 04, 2011 at 10:11:40PM +0100, Tollef Fog Heen wrote:
> >From the proposed policy patch:

> +  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.

> My system actually already has upstart installed, but doesn't use it, so
> upstart's telinit will have to be fixed to not report «upstart» in its
> version string if the running init is not upstart.  That's slightly
> orthogonal to this bug report, but it shows that you can't necessarily
> depend on the output of --version and such to know what's running.  This
> will also affect people on migration from one init system to another.

Right.  I've looked around, and the better interface to use here is 'initctl
version'; this command tries to query the running init daemon over the
upstart-specific control socket and fails if it can't connect.  Of course,
if the initctl command doesn't exist at all on the system, this will fail.

> +            Dependency-based boot managers for SysV init scripts, such as
> +            <package>insserv</package>, may bypass a given init script
> +            entirely when an equivalent upstart job is present, to avoid
> +            unnecessary forking of no-op init scripts. 

> What happens to the dependency resolution of insserv in that case?  I'd
> much rather have insserv not do anything and the non-sysvinit init
> system be smart and parse LSB headers rather than insserv seeing that A
> depends B, but B is missing (since it's provided by a systemd
> service/upstart job) and then flake out.

This was a good question, which took me a while to answer.  The answer I've
come up with is
<http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2011-October/005345.html>.
It's a deliberate design decision for upstart to not support parsing of LSB
headers of init scripts, instead delegating this to insserv (and delegating
the execution to /etc/init.d/rc).  The linked patch, however, allows
startpar to recognize when a dependency should be satisfied by an upstart
job instead of by the corresponding init script.

> I'd also like us to forbid depending on implementation-specific scripts
> such as mountkernfs since there won't necessarily be anything that maps
> to in a non-sysvinit world.  The exception would be if an init script is
> shipped as part of the init system, so sysv-rc's scripts could have
> dependencies on mountkernfs, but random daemons could not.

udev already depends on mountkernfs as part of the rcS sequence.  Of course,
the entire rcS sequence should be replaced by the alternative init system,
but this will still require cooperation between several packages.

I'm not sure whether this needs to be documented in Policy per se, or with
what level of granularity.   I do think there's a bootstrapping tangle here,
in that I don't want to start pushing patches to sysvinit, lsb-base, and
debhelper until we have the basic Policy agreed upon, and I don't think
we'll be able to discern a correct policy for things like mountkernfs until
we've gotten fairly far along with implementing it.  So if you don't mind,
I'd like to split this particular issue off to be dealt with separately.

> A final thing I'd like to get added to the policy text is how
> standardised facility names are handled.  insserv for some reason does
> not handle init scripts providing $x-display-manager and similar, but
> requires those to be added to the insserv configuration file.  We should
> either require init implementations to allow providing the standardised
> facility names or we should put that information somewhere in a a
> neutral location and format so all init implementations can make use of
> it.

Does this refer to aliases standardized in the LSB, or to some other
standard?  (I'd answer this for myself, but once again it looks like I can't
find the text of the LSB when I'm looking for it...)

Updated patch attached.

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
[0001-Document-generic-and-upstart-specific-init-system-re.patch (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Tue, 18 Oct 2011 05:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 18 Oct 2011 05:09:03 GMT) Full text and rfc822 format available.

Message #124 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>, 591791@bugs.debian.org
Cc: Scott James Remnant <scott@netsplit.com>, Michael Biebl <biebl@debian.org>, Petter Reinholdtsen <pere@hungry.com>, James Hunt <james.hunt@canonical.com>
Subject: Re: Bug#591791: extend init.d policy to permit upstart jobs and describe their use
Date: Mon, 17 Oct 2011 22:06:55 -0700
[Message part 1 (text/plain, inline)]
Hi Jonathan,

On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote:
> > +          tasks at boot time.  However, any package integrating with other
> > +          init systems must also be backwards-compatible with
> > +          <package>sysvinit</package> by providing a SysV-style init script
> > +          with the same name as and equivalent functionality to any
> > +          init-specific job, as this is the only start-up configuration
> > +          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.

> Maybe policy could allow (but discourage) packages that only support
> some non-Sys-V init system as long as they include a dependency
> indicating so?

I don't think that's something that should be allowed.  You can only have
one init system installed at a time; and all of the interesting alternatives
to sysvinit are currently Linux-only.  So if maintainers start choosing to
only support one of the alternatives, they will quickly fragment the
distribution (because not all maintainers are going to choose the *same*
alternative), and they will render their packages unusable on our non-Linux
ports.  The only reason for any package to provide only an upstart job, or
only a systemd config, is if it's a cooperating package providing part of
the base boot sequence for that init system.  (E.g., mountall for upstart.)

> One of the advantages of upstart and its kin is the simpler
> configuration, after all, so I can imagine some maintainers wanting to
> take advantage of that and not having time to debug a standard init
> script.  The example that led me to mention this is Bug#422139; it is
> not quite the same issue but is related.

Having written many upstart jobs, I understand the appeal of not having to
maintain a sysvinit script for backwards-compatibility.  However, the slow
movement of upstart in Debian so far, and this policy bug proposing rules
for alternate init systems, are specifically about ensuring that we do *not*
lose backwards-compatibility.

Now, if someone were to write a tool to automatically translate an upstart
job into an init script, that might be an interesting way to handle this;
but most upstart jobs will be missing information about things like how to
ask a daemon to create a pid file, or where the pid file will be stored, so
the applications might still be limited.

> As a naïve user, I'd prefer the SysV init scripts to pass on requests to
> upstart when upstart is running; is that feasible?

It would be feasible to pass requests to upstart, but it would be
unnecessary.  If the upstart job is properly declared, upstart will have
already started it in the runlevel (or queued it for starting) before the
init script ever has a chance to ask; and for admin invocations, a frontend
like the 'service' command is more user-friendly anyway.

> I suspect it would be best to make the language init system neutral,
> and to say something to this effect:

> . sysvinit scripts need to behave reasonably regardless of the init
>   system in use.  So:

>  i. If an equivalent job file for another init system is present, the
>     sysvinit script will not be automatically invoked by that init
>     system when switching runlevels.  In this case, when that init
>     system is in use, the sysvinit script (if invoked by hand, for
>     example) must either delegate requests to the init system or
>     error out without doing anything.  Don't fight with init(8).

> ii. Even if an equivalent job file for another init system is
>     available, the sysvinit script should behave as advertised (and
>     not be a no-op) when init is sysvinit.

I agree that these are the relevant principles, but I think Policy should
spell out exact requirements for each init system.

Cheers,
-- 
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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Tue, 18 Oct 2011 05:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tollef Fog Heen <tfheen@err.no>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 18 Oct 2011 05:24:03 GMT) Full text and rfc822 format available.

Message #129 received at 591791@bugs.debian.org (full text, mbox):

From: Tollef Fog Heen <tfheen@err.no>
To: Steve Langasek <vorlon@debian.org>
Cc: 591791@bugs.debian.org
Subject: Re: Bug#591791: systemd point of view
Date: Tue, 18 Oct 2011 07:21:33 +0200
]] Steve Langasek 

Hi Steve,

| Picking up this policy thread after a bit...  Let's see if we can drive this
| to a conclusion now.

Sounds good.

| Right.  I've looked around, and the better interface to use here is 'initctl
| version'; this command tries to query the running init daemon over the
| upstart-specific control socket and fails if it can't connect.  Of course,
| if the initctl command doesn't exist at all on the system, this will fail.

Works for me.  I can most likely get a systemctl version command added
to systemd.  (Or systemctl ping to just see if init is alive.)

| > +            Dependency-based boot managers for SysV init scripts, such as
| > +            <package>insserv</package>, may bypass a given init script
| > +            entirely when an equivalent upstart job is present, to avoid
| > +            unnecessary forking of no-op init scripts. 
| 
| > What happens to the dependency resolution of insserv in that case?  I'd
| > much rather have insserv not do anything and the non-sysvinit init
| > system be smart and parse LSB headers rather than insserv seeing that A
| > depends B, but B is missing (since it's provided by a systemd
| > service/upstart job) and then flake out.
| 
| This was a good question, which took me a while to answer.  The answer I've
| come up with is
| <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2011-October/005345.html>.
| It's a deliberate design decision for upstart to not support parsing of LSB
| headers of init scripts, instead delegating this to insserv (and delegating
| the execution to /etc/init.d/rc).  The linked patch, however, allows
| startpar to recognize when a dependency should be satisfied by an upstart
| job instead of by the corresponding init script.

If insserv just doesn't do anything when it sees systemd, that'd be fine

| > I'd also like us to forbid depending on implementation-specific scripts
| > such as mountkernfs since there won't necessarily be anything that maps
| > to in a non-sysvinit world.  The exception would be if an init script is
| > shipped as part of the init system, so sysv-rc's scripts could have
| > dependencies on mountkernfs, but random daemons could not.
| 
| udev already depends on mountkernfs as part of the rcS sequence.  Of course,
| the entire rcS sequence should be replaced by the alternative init system,
| but this will still require cooperation between several packages.

We have ~115 init scripts which claims to start in rcS, replacing all of
these with systemd units and upstart jobs sounds like a bit too much, I
think, especially if this should come from the init system itself.

(I'm sure there are things in rcS that shouldn't be there too.  Fixing
that would be great.)

| I'm not sure whether this needs to be documented in Policy per se, or with
| what level of granularity.   I do think there's a bootstrapping tangle here,
| in that I don't want to start pushing patches to sysvinit, lsb-base, and
| debhelper until we have the basic Policy agreed upon, and I don't think
| we'll be able to discern a correct policy for things like mountkernfs until
| we've gotten fairly far along with implementing it.  So if you don't mind,
| I'd like to split this particular issue off to be dealt with separately.

Ok, I can live with that.  Alternatively, we could require packages
depending on implementation-specific init scripts to also ship
configurations for alternative init systems.

| > A final thing I'd like to get added to the policy text is how
| > standardised facility names are handled.  insserv for some reason does
| > not handle init scripts providing $x-display-manager and similar, but
| > requires those to be added to the insserv configuration file.  We should
| > either require init implementations to allow providing the standardised
| > facility names or we should put that information somewhere in a a
| > neutral location and format so all init implementations can make use of
| > it.
| 
| Does this refer to aliases standardized in the LSB, or to some other
| standard?  (I'd answer this for myself, but once again it looks like I can't
| find the text of the LSB when I'm looking for it...)

(refspecs.lf.o is still down, it seems)

They're (mostly) standardised in the LSB, but iirc Debian adds some of
their own.  It seems like systemd might grow code to read the insserv
configuration files, but I'd rather it just lived in init scripts
themselves.

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.

Also, I'm a bit annoyed about you grabbing /etc/init, not because
systemd wants it for anything, but because it'll destroy tab completion
for those of us doing /etc/in<TAB>/foo restart so the namespace grab
will affect not only upstart users, but everybody.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Tue, 18 Oct 2011 05:24:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 18 Oct 2011 05:24:05 GMT) Full text and rfc822 format available.

Message #134 received at 591791@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Steve Langasek <vorlon@debian.org>
Cc: 591791@bugs.debian.org, Scott James Remnant <scott@netsplit.com>, Michael Biebl <biebl@debian.org>, Petter Reinholdtsen <pere@hungry.com>, James Hunt <james.hunt@canonical.com>
Subject: Re: extend init.d policy to permit upstart jobs and describe their use
Date: Tue, 18 Oct 2011 00:22:18 -0500
Hi,

Steve Langasek wrote:
> On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote:

>> Maybe policy could allow (but discourage) packages that only support
>> some non-Sys-V init system as long as they include a dependency
>> indicating so?
>
> I don't think that's something that should be allowed.  You can only have
> one init system installed at a time

Exactly.  That makes this old suggestion of mine a very bad idea, and
I'm glad you caught it back then, too. ;-)

[...]
>> As a naïve user, I'd prefer the SysV init scripts to pass on requests to
>> upstart when upstart is running; is that feasible?
[...]
> for admin invocations, a frontend
> like the 'service' command is more user-friendly anyway.

I don't agree, but I agree that it's not worth the fuss to teach
/etc/init.d/foo to pass on requests and handle all edge cases
appropriately, so this is academic.

[...]
>> . sysvinit scripts need to behave reasonably regardless of the init
>>   system in use.  So:
>
>>  i. If an equivalent job file for another init system is present, the
>>     sysvinit script will not be automatically invoked by that init
>>     system when switching runlevels.  In this case, when that init
>>     system is in use, the sysvinit script (if invoked by hand, for
>>     example) must either delegate requests to the init system or
>>     error out without doing anything.  Don't fight with init(8).
>
>> ii. Even if an equivalent job file for another init system is
>>     available, the sysvinit script should behave as advertised (and
>>     not be a no-op) when init is sysvinit.
>
> I agree that these are the relevant principles, but I think Policy should
> spell out exact requirements for each init system.

I guess so.  (ii) is already implied by "don't be buggy".  (i) is
probably worth spelling out, though --- I'll look at your patch to see
if it does so.

In an ideal world, (i) would be enough [since it determines the
behavior] and packagers could experiment and refer to each init
system's interface documentation [e.g.  manpages] for details, but I
understand that documenting details on implementation strategy in one
place can be useful for making the result easy to understand.

Thanks again for your work on this!
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Tue, 18 Oct 2011 05:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 18 Oct 2011 05:42:03 GMT) Full text and rfc822 format available.

Message #139 received at 591791@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Steve Langasek <vorlon@debian.org>
Cc: 591791@bugs.debian.org, Scott James Remnant <scott@netsplit.com>, Michael Biebl <biebl@debian.org>, Petter Reinholdtsen <pere@hungry.com>, James Hunt <james.hunt@canonical.com>
Subject: Re: extend init.d policy to permit upstart jobs and describe their use
Date: Tue, 18 Oct 2011 00:39:22 -0500
Jonathan Nieder wrote:

> In an ideal world, (i) would be enough [since it determines the
> behavior] and packagers could experiment

Just to be clear: I was reading from the point of view of what a
packager of an ordinary daemon needs to do.  But the requirements on
init systems are important, too[1].  Sorry about neglecting that.

[1] Examples: to what extent an init system is allowed to ignore
init scripts provided by other packages when it provides its own
native equivalents.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 26 Dec 2011 19:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 26 Dec 2011 19:09:03 GMT) Full text and rfc822 format available.

Message #144 received at 591791@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Tollef Fog Heen <tfheen@err.no>
Cc: 591791@bugs.debian.org, Steve Langasek <vorlon@debian.org>
Subject: Re: Bug#591791: systemd point of view
Date: Mon, 26 Dec 2011 11:04:27 -0800
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/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Sun, 26 Feb 2012 21:39:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 26 Feb 2012 21:39:09 GMT) Full text and rfc822 format available.

Message #149 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: Tollef Fog Heen <tfheen@err.no>, 591791@bugs.debian.org
Subject: Re: Bug#591791: systemd point of view
Date: Sun, 26 Feb 2012 13:36:19 -0800
[Message part 1 (text/plain, inline)]
On Mon, Dec 26, 2011 at 11:04:27AM -0800, Russ Allbery wrote:
> > 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?

So currently, invoke-rc.d is part of the sysv-rc package, and there's an
alternative implementation in the file-rc package.  I had envisioned that
these packages would continue to own the invoke-rc.d and update-rc.d
interfaces, as they do on Ubuntu, and be the focal point for bridging the
differences between the different init systems.  I didn't mean that the init
systems themselves should implement invoke-rc.d, but that the one coming
with whichever implementation of "rc" is used on the system should support
all the init systems.

Shipping an invoke-rc.d implementation in upstart and/or systemd would mean
either a lot of code duplication, or a pass-through with dpkg-divert.  I'm
not enthusiastic about either idea, but if push came to shove (i.e., if the
sysvinit maintainers rejected patches to support upstart in invoke-rc.d), I
would opt for the latter.

> 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?)

Bug #660824, with initial positive feedback from one of the sysvinit
comaintainers.  (This should be corrected to say "startpar" rather than
"insserv" since insserv only generates the dependency information, it's
startpar that acts on it at boot time.  Fixed in my patch.)

> 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?

I guess that's bug #645540, and subsequent discussion on debian-devel in
http://lists.debian.org/debian-devel/2012/02/msg00309.html ff.  Policy
doesn't really speak to this at present anyway, so I would be content to let
the maintainers of the small set of packages involved figure this out among
themselves.

> 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.

Ok, example included based on the patch in bug #661109.

Updated patch attached.

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
[0001-Document-generic-and-upstart-specific-init-system-re.patch (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Sun, 26 Feb 2012 23:15:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 26 Feb 2012 23:15:06 GMT) Full text and rfc822 format available.

Message #154 received at 591791@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: 591791@bugs.debian.org
Cc: Tollef Fog Heen <tfheen@err.no>
Subject: Re: [PATCH] Document generic and upstart-specific init-system requirements
Date: Sun, 26 Feb 2012 17:12:24 -0600
Steve Langasek wrote:

> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -7188,6 +7188,74 @@ Reloading <var>description</var> configuration...done.
[...]
> +          <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.

When I first read this, I wondered if in a postinst containing

	# Automatically added by dh_installinit
	if [ -x "/etc/init.d/vsftpd" ]; then
		update-rc.d vsftpd start 20 2 3 4 5 . stop 80 1 . >/dev/null
		invoke-rc.d vsftpd start || exit $?
	fi
	# End automatically added section

the "invoke-rc.d vsftpd start" line should be removed when I add an upstart
job.  Possible cause: the word "directly" is being asked to do too much.

Would the following be too strict?

	Maintainer scripts should not execute /etc/init.d/<package> scripts
	directly.

What init script actions would a maintainer script call without using
the invoke-rc.d wrapper?

The rest looks good to me, and I imagine the effect of some upstart
and systemd jobs integrated in the archive this way would be quite
nice.  (For example, maybe it would dispell some worries about the
possibility of event-based boot without commiting too early to a
particular init system.)

Thanks,
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Sun, 26 Feb 2012 23:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 26 Feb 2012 23:57:03 GMT) Full text and rfc822 format available.

Message #159 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>, 591791@bugs.debian.org
Cc: Tollef Fog Heen <tfheen@err.no>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Sun, 26 Feb 2012 15:54:53 -0800
[Message part 1 (text/plain, inline)]
On Sun, Feb 26, 2012 at 05:12:24PM -0600, Jonathan Nieder wrote:
> > --- a/policy.sgml
> > +++ b/policy.sgml
> > @@ -7188,6 +7188,74 @@ Reloading <var>description</var> configuration...done.
> [...]
> > +          <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.

> When I first read this, I wondered if in a postinst containing

> 	# Automatically added by dh_installinit
> 	if [ -x "/etc/init.d/vsftpd" ]; then
> 		update-rc.d vsftpd start 20 2 3 4 5 . stop 80 1 . >/dev/null
> 		invoke-rc.d vsftpd start || exit $?
> 	fi
> 	# End automatically added section

> the "invoke-rc.d vsftpd start" line should be removed when I add an upstart
> job.  Possible cause: the word "directly" is being asked to do too much.

> Would the following be too strict?

> 	Maintainer scripts should not execute /etc/init.d/<package> scripts
> 	directly.

I think you've misunderstood the intent here.  When upstart is installed, it
provides *commands* called "start", "restart", "reload", and "stop" in
/sbin.  These are the commands that must not be called from maintainer
scripts.  It has nothing to do with invocation of /etc/init.d/<package>
scripts, which is already prohibited elsewhere in policy.

Is there a word that you think would be less ambiguous than "command" for
expressing this?

-- 
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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 27 Feb 2012 00:03:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 27 Feb 2012 00:03:07 GMT) Full text and rfc822 format available.

Message #164 received at 591791@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Steve Langasek <vorlon@debian.org>
Cc: 591791@bugs.debian.org, Jonathan Nieder <jrnieder@gmail.com>, Tollef Fog Heen <tfheen@err.no>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Sun, 26 Feb 2012 16:00:11 -0800
Steve Langasek <vorlon@debian.org> writes:

> I think you've misunderstood the intent here.  When upstart is
> installed, it provides *commands* called "start", "restart", "reload",
> and "stop" in /sbin.  These are the commands that must not be called
> from maintainer scripts.  It has nothing to do with invocation of
> /etc/init.d/<package> scripts, which is already prohibited elsewhere in
> policy.

> Is there a word that you think would be less ambiguous than "command" for
> expressing this?

Oh, yes, I misunderstood that too.  How about:

        These maintainer scripts must not call the upstart
        <prgn>start</prgn>, <prgn>restart</prgn>, <prgn>reload</prgn>, or
        <prgn>stop</prgn> interfaces directly.

which uses the same term (interfaces) that is used for calling invoke-rc.d
and update-rc.d?

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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 27 Feb 2012 01:03:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 27 Feb 2012 01:03:10 GMT) Full text and rfc822 format available.

Message #169 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Russ Allbery <rra@debian.org>, 591791@bugs.debian.org
Cc: Jonathan Nieder <jrnieder@gmail.com>, Tollef Fog Heen <tfheen@err.no>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Sun, 26 Feb 2012 17:01:59 -0800
[Message part 1 (text/plain, inline)]
On Sun, Feb 26, 2012 at 04:00:11PM -0800, Russ Allbery wrote:
> Steve Langasek <vorlon@debian.org> writes:

> > I think you've misunderstood the intent here.  When upstart is
> > installed, it provides *commands* called "start", "restart", "reload",
> > and "stop" in /sbin.  These are the commands that must not be called
> > from maintainer scripts.  It has nothing to do with invocation of
> > /etc/init.d/<package> scripts, which is already prohibited elsewhere in
> > policy.

> > Is there a word that you think would be less ambiguous than "command" for
> > expressing this?

> Oh, yes, I misunderstood that too.  How about:

>         These maintainer scripts must not call the upstart
>         <prgn>start</prgn>, <prgn>restart</prgn>, <prgn>reload</prgn>, or
>         <prgn>stop</prgn> interfaces directly.

> which uses the same term (interfaces) that is used for calling invoke-rc.d
> and update-rc.d?

Looks good to me.  Attached.

-- 
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
[0001-Document-generic-and-upstart-specific-init-system-re.patch (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 02 Mar 2012 04:15:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 02 Mar 2012 04:15:07 GMT) Full text and rfc822 format available.

Message #174 received at 591791@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Steve Langasek <vorlon@debian.org>
Cc: 591791@bugs.debian.org, Jonathan Nieder <jrnieder@gmail.com>, Tollef Fog Heen <tfheen@err.no>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Thu, 01 Mar 2012 20:10:43 -0800
Steve Langasek <vorlon@debian.org> writes:
> On Sun, Feb 26, 2012 at 04:00:11PM -0800, Russ Allbery wrote:

>> Oh, yes, I misunderstood that too.  How about:

>>         These maintainer scripts must not call the upstart
>>         <prgn>start</prgn>, <prgn>restart</prgn>, <prgn>reload</prgn>, or
>>         <prgn>stop</prgn> interfaces directly.

>> which uses the same term (interfaces) that is used for calling invoke-rc.d
>> and update-rc.d?

> Looks good to me.  Attached.

[...]

Seconded.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 19:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Adam D. Barratt" <adam@adam-barratt.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 19:15:03 GMT) Full text and rfc822 format available.

Message #179 received at 591791@bugs.debian.org (full text, mbox):

From: "Adam D. Barratt" <adam@adam-barratt.org.uk>
To: Steve Langasek <vorlon@debian.org>, 591791@bugs.debian.org
Cc: Russ Allbery <rra@debian.org>, Jonathan Nieder <jrnieder@gmail.com>, Tollef Fog Heen <tfheen@err.no>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 19:09:17 +0000
On Sun, 2012-02-26 at 17:01 -0800, Steve Langasek wrote:
> On Sun, Feb 26, 2012 at 04:00:11PM -0800, Russ Allbery wrote:
> > Oh, yes, I misunderstood that too.  How about:
> 
> >         These maintainer scripts must not call the upstart
> >         <prgn>start</prgn>, <prgn>restart</prgn>, <prgn>reload</prgn>, or
> >         <prgn>stop</prgn> interfaces directly.
> 
> > which uses the same term (interfaces) that is used for calling invoke-rc.d
> > and update-rc.d?
> 
> Looks good to me.  Attached.

Seconded.

Regards,

Adam





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 19:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 19:57:04 GMT) Full text and rfc822 format available.

Message #184 received at 591791@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: "Adam D. Barratt" <adam@adam-barratt.org.uk>, 591791@bugs.debian.org, Steve Langasek <vorlon@debian.org>, Tollef Fog Heen <tfheen@err.no>, Russ Allbery <rra@debian.org>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 20:53:15 +0100
[Message part 1 (text/plain, inline)]
On 16.03.2012 20:09, Adam D. Barratt wrote:
> On Sun, 2012-02-26 at 17:01 -0800, Steve Langasek wrote:
>> On Sun, Feb 26, 2012 at 04:00:11PM -0800, Russ Allbery wrote:
>>> Oh, yes, I misunderstood that too.  How about:
>>
>>>         These maintainer scripts must not call the upstart
>>>         <prgn>start</prgn>, <prgn>restart</prgn>, <prgn>reload</prgn>, or
>>>         <prgn>stop</prgn> interfaces directly.
>>
>>> which uses the same term (interfaces) that is used for calling invoke-rc.d
>>> and update-rc.d?
>>
>> Looks good to me.  Attached.
> 

As I've already mentioned before, I don't like the approach, that any
init script should use something like:

> if [ "$1" = start ] && which initctl && initctl version | grep -q upstart; then
> exit 1
> then

It seems much more sensible to me, to move all this logic into a
separate shell library, and instead of hardcoding the above commands in
the sysv init script, policy should just mention that maintainers that
wish to provide both an upstart job and sysv init script would source
this library in the sysv init script.

Otherwise it will lead to copy&paste and maintenance nightmare

Also, the proposal looks underspecified to me: What happens for other
actions, like stop/restart/reload/force-reload?

What happens in maintainers scripts that call invoke-rc.d service start?
Will they now suddenly all fail? How will invoke-rc.d behave when the
package both installs a upstart job and sysv init script?

How will "service" behave?

There are too many open questions, so I can't support the text in the
current form.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 20:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 20:09:03 GMT) Full text and rfc822 format available.

Message #189 received at 591791@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Michael Biebl <biebl@debian.org>
Cc: 591791@bugs.debian.org, "Adam D. Barratt" <adam@adam-barratt.org.uk>, Steve Langasek <vorlon@debian.org>, Tollef Fog Heen <tfheen@err.no>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 13:07:08 -0700
Michael Biebl <biebl@debian.org> writes:

> It seems much more sensible to me, to move all this logic into a
> separate shell library, and instead of hardcoding the above commands in
> the sysv init script, policy should just mention that maintainers that
> wish to provide both an upstart job and sysv init script would source
> this library in the sysv init script.

> Otherwise it will lead to copy&paste and maintenance nightmare

This seems like a reasonable idea.  Steve, what do you think of having
upstart provide such a shell library?  Then init scripts could contain
code along the lines of:

    if [ -r /lib/init/upstart.sh ] ; then
        . /lib/init/upstart.sh
        ignore_if_upstart
    fi

If upstart and systemd can agree on the same invocation semantics for the
shell library, we could even provide a shell library that handled both and
make this more generic.

> Also, the proposal looks underspecified to me: What happens for other
> actions, like stop/restart/reload/force-reload?

My understanding is that calling those actions directly via the init
script is not necessarily supported and invoke-rc.d should be used
instead.  That should probably be spelled out explicitly.

> What happens in maintainers scripts that call invoke-rc.d service start?
> Will they now suddenly all fail? How will invoke-rc.d behave when the
> package both installs a upstart job and sysv init script?

Steve's patch requires that invoke-rc.d do the right thing:

+          <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 upstart <prgn>start</prgn>,
+            <prgn>restart</prgn>, <prgn>reload</prgn>, or <prgn>stop</prgn>
+            interfaces directly.  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.
+          </p>

> How will "service" behave?

service already handles upstart directly.  It presumably could and should
be extended in an equivalent way to handle systemd.  I don't think that
needs to be spelled out in Policy, since service is not an interface that
(at least at the moment) is standardized in Policy.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 20:18:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 20:18:06 GMT) Full text and rfc822 format available.

Message #194 received at 591791@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Michael Biebl <biebl@debian.org>
Cc: 591791@bugs.debian.org, "Adam D. Barratt" <adam@adam-barratt.org.uk>, Tollef Fog Heen <tfheen@err.no>
Subject: Re: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 15:14:18 -0500
Hi Michael,

Michael Biebl wrote:

> As I've already mentioned before, I don't like the approach, that any
> init script should use something like:
>
>> if [ "$1" = start ] && which initctl && initctl version | grep -q upstart
>> then
>>	exit 1
>> fi
>
> It seems much more sensible to me, to move all this logic into a
> separate shell library

Would this shell library be four lines?  What package provides it?
Would it be something that can be used in init scripts shared with
other distros (like the above can)?  Would it be enough to provide
such a shell library and encourage people to use it, or should policy
mandate its use to prepare for the shell library to change in some
appropriate way in the future?

By the way, the above example writes the path to initctl to the
terminal when it is present, which I imagine is not intended.

[...]
> Also, the proposal looks underspecified to me: What happens for other
> actions, like stop/restart/reload/force-reload?

Yes, I agree.  The example should be corrected to prevent the daemon
from being started by the restart and force-reload actions.

> What happens in maintainers scripts that call invoke-rc.d service start?
> Will they now suddenly all fail?

According to the proposal,

	implementations of "invoke-rc.d" 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.

> How will "service" behave?

Doesn't seem like a matter for policy unless packages need to use
"service" directly in some circumstance, but if I remember correctly
then upstart overrides the "service" command.

Hope that helps,
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 20:21:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 20:21:05 GMT) Full text and rfc822 format available.

Message #199 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Michael Biebl <biebl@debian.org>
Cc: "Adam D. Barratt" <adam@adam-barratt.org.uk>, 591791@bugs.debian.org, Tollef Fog Heen <tfheen@err.no>, Russ Allbery <rra@debian.org>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 13:18:24 -0700
[Message part 1 (text/plain, inline)]
On Fri, Mar 16, 2012 at 08:53:15PM +0100, Michael Biebl wrote:

> As I've already mentioned before, I don't like the approach, that any
> init script should use something like:

> > if [ "$1" = start ] && which initctl && initctl version | grep -q upstart; then
> > exit 1
> > then

> It seems much more sensible to me, to move all this logic into a
> separate shell library, and instead of hardcoding the above commands in
> the sysv init script, policy should just mention that maintainers that
> wish to provide both an upstart job and sysv init script would source
> this library in the sysv init script.

This is an example implementation only.  A patch has already been submitted
for lsb-base, but /lib/lsb/init-functions is not specified anywhere else in
policy so I don't think it's appropriate to have policy now mandate its use
in this specific case.

> Otherwise it will lead to copy&paste and maintenance nightmare

> Also, the proposal looks underspecified to me: What happens for other
> actions, like stop/restart/reload/force-reload?

Well, it would be inappropriate to refuse to stop the service because
upstart was running.  The more likely outcome is that the init script will
not be able to find the running process, and will therefore exit 0 anyway as
a no-op.  So I don't think there are any new requirements here (which is why
I didn't spell it out).

Likewise, the behavior of reload should not change.

Restart and force-reload are indeed trickier, and I hadn't considered those
in detail.  What do you think should happen here?  We certainly shouldn't
allow these interfaces to start the service outside of upstart control.
Should they call 'start $service' instead?

> What happens in maintainers scripts that call invoke-rc.d service start?
> Will they now suddenly all fail? How will invoke-rc.d behave when the
> package both installs a upstart job and sysv init script?

Doesn't this language already cover that?

   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.

The only corner case is when a service which uses invoke-rc.d restart in the
postinst, instead of invoke-rc.d stop in prerm + invoke-rc.d start in the
postinst, transitions to an upstart job.  In that case, the package would
need to take special care to ensure the sysvinit script is stopped on
upgrade, since 'invoke-rc.d restart' won't do it once the upstart job has
been unpacked.  I don't think that complexity should be added to
invoke-rc.d, because it is such a corner case; nor do I see a need, at this
point, to spell this out in policy because it follows directly from the
requirements that are specified.

> How will "service" behave?

'service' is not a policy interface.  Why do you want to make it one as a
precondition of letting people ship upstart jobs in the archive?

The answer, in any case, is that service should automatically prefer the
native jobs for whichever init is running, as this should always be the
correct answer provided the package maintainer scripts have done their job.

-- 
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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 20:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 20:27:03 GMT) Full text and rfc822 format available.

Message #204 received at 591791@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Steve Langasek <vorlon@debian.org>
Cc: "Adam D. Barratt" <adam@adam-barratt.org.uk>, 591791@bugs.debian.org, Tollef Fog Heen <tfheen@err.no>, Russ Allbery <rra@debian.org>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 21:25:17 +0100
[Message part 1 (text/plain, inline)]
On 16.03.2012 21:18, Steve Langasek wrote:
> On Fri, Mar 16, 2012 at 08:53:15PM +0100, Michael Biebl wrote:
> 
>> As I've already mentioned before, I don't like the approach, that any
>> init script should use something like:
> 
>>> if [ "$1" = start ] && which initctl && initctl version | grep -q upstart; then
>>> exit 1
>>> then
> 
>> It seems much more sensible to me, to move all this logic into a
>> separate shell library, and instead of hardcoding the above commands in
>> the sysv init script, policy should just mention that maintainers that
>> wish to provide both an upstart job and sysv init script would source
>> this library in the sysv init script.
> 
> This is an example implementation only.  A patch has already been submitted
> for lsb-base, but /lib/lsb/init-functions is not specified anywhere else in
> policy so I don't think it's appropriate to have policy now mandate its use
> in this specific case.
> 
>> Otherwise it will lead to copy&paste and maintenance nightmare
> 
>> Also, the proposal looks underspecified to me: What happens for other
>> actions, like stop/restart/reload/force-reload?
> 
> Well, it would be inappropriate to refuse to stop the service because
> upstart was running.  The more likely outcome is that the init script will
> not be able to find the running process, and will therefore exit 0 anyway as
> a no-op.  So I don't think there are any new requirements here (which is why
> I didn't spell it out).

If you kill the daemon from the sysv init script, upstart will just
respawn it (if respawn is set) or mark it as failed.

Personally, I would just prefer, if the shell library would forward the
action requests to the native init system.


Another problematic issue that comes to mind, is packages installing
dhcp and ifup.d hooks which call /etc/init.d/<service> <start>

From my recollection, there are at least a few that do this, the most
prominent one is nfs-common.

Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 20:39:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 20:39:03 GMT) Full text and rfc822 format available.

Message #209 received at 591791@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Michael Biebl <biebl@debian.org>
Cc: Steve Langasek <vorlon@debian.org>, "Adam D. Barratt" <adam@adam-barratt.org.uk>, 591791@bugs.debian.org, Tollef Fog Heen <tfheen@err.no>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 13:38:10 -0700
Michael Biebl <biebl@debian.org> writes:

> Another problematic issue that comes to mind, is packages installing
> dhcp and ifup.d hooks which call /etc/init.d/<service> <start>

> From my recollection, there are at least a few that do this, the most
> prominent one is nfs-common.

This probably should already be a Policy violation, saying that they
should use invoke-rc.d instead.  Is there any drawback to them using
invoke-rc.d?

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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 20:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 20:48:03 GMT) Full text and rfc822 format available.

Message #214 received at 591791@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: 591791@bugs.debian.org, Michael Biebl <biebl@debian.org>, "Adam D. Barratt" <adam@adam-barratt.org.uk>, Tollef Fog Heen <tfheen@err.no>
Subject: Re: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 15:46:03 -0500
Russ Allbery wrote:

> This probably should already be a Policy violation, saying that they
> should use invoke-rc.d instead.  Is there any drawback to them using
> invoke-rc.d?

Yes, I think there is a drawback.  Forgetting about upstart and
systemd for the moment, if I use "/etc/init.d/<service> start" or
"service <service> start" directly, I get a guarantee that the service
has been started.  If I use "invoke-rc.d <service> start", then the
policy hook can intercept my request and cause the daemon not to be
started but report success.

I'm not sure what the right thing to do in that case is.

Another downside is that invoke-rc.d is Debian-specific.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 20:51:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 20:51:03 GMT) Full text and rfc822 format available.

Message #219 received at 591791@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Steve Langasek <vorlon@debian.org>
Cc: 591791@bugs.debian.org, Tollef Fog Heen <tfheen@err.no>, Russ Allbery <rra@debian.org>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 21:47:31 +0100
[Message part 1 (text/plain, inline)]
On 16.03.2012 21:25, Michael Biebl wrote:

> Personally, I would just prefer, if the shell library would forward the
> action requests to the native init system.

I still like this part of the original upstart-job idea (Steve knows the
details), simply because admins are used to the
/etc/init.d/<service> <action>
interface. Muscle memory and all.

Where the upstart-job idea failed, was the idea, that we could get away
without sysv init scripts (on Debian). It is obvious, that this won't
happen anytime soon.

For those who don't know upstart-job:
In Ubuntu, packages which ship a native upstart job foo, have a symlink
/etc/init.d/foo → /lib/init/upstart-job

If you type /etc/init.d/foo <action>
upstart-job will translate those requests into "initctl <action> foo".

What I would do differently nowadays, is change the way this works:
Packages continue to ship a sysv init script
If they ship a native upstart (or systemd) service file, they source a
shell library, which redirect those requests to the native service.

Currently we do that in systemd by (ab)using /lib/lsb/init-functions
which is a hack, so I'd like to do that properly.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 20:51:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 20:51:04 GMT) Full text and rfc822 format available.

Message #224 received at 591791@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 591791@bugs.debian.org, Michael Biebl <biebl@debian.org>, "Adam D. Barratt" <adam@adam-barratt.org.uk>, Tollef Fog Heen <tfheen@err.no>
Subject: Re: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 13:49:28 -0700
Jonathan Nieder <jrnieder@gmail.com> writes:
> Russ Allbery wrote:

>> This probably should already be a Policy violation, saying that they
>> should use invoke-rc.d instead.  Is there any drawback to them using
>> invoke-rc.d?

> Yes, I think there is a drawback.  Forgetting about upstart and systemd
> for the moment, if I use "/etc/init.d/<service> start" or "service
> <service> start" directly, I get a guarantee that the service has been
> started.  If I use "invoke-rc.d <service> start", then the policy hook
> can intercept my request and cause the daemon not to be started but
> report success.

> I'm not sure what the right thing to do in that case is.

That seems like a feature, not a bug, in the case of configuration
installed by Debian packages such as what's cited in this part of the
thread.  If I have a policy rule that says not to run that init script, I
mean it, and I don't want ifup running it anyway.

> Another downside is that invoke-rc.d is Debian-specific.

So are the network hooks under discussion.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 21:19:45 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 21:19:58 GMT) Full text and rfc822 format available.

Message #229 received at 591791@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Steve Langasek <vorlon@debian.org>, 591791@bugs.debian.org
Cc: "Adam D. Barratt" <adam@adam-barratt.org.uk>, Tollef Fog Heen <tfheen@err.no>, Russ Allbery <rra@debian.org>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 22:05:32 +0100
[Message part 1 (text/plain, inline)]
On 16.03.2012 21:18, Steve Langasek wrote:

>> What happens in maintainers scripts that call invoke-rc.d service start?
>> Will they now suddenly all fail? How will invoke-rc.d behave when the
>> package both installs a upstart job and sysv init script?
> 
> Doesn't this language already cover that?
> 
>    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.

Seems I missed that, sorry. Yeah, invoke-rc.d forwarding the request to
the native implementation looks fine in general.

I think it would also make sense to specify, which actions are forwarded.
I think policy mandates start/stop/restart/force-reload, status and
reload are optional iirc. How would those be mapped to the corresponding
upstart (or systemd) jobs.

What are we doing about custom actions?
Contrary to sysvinit, upstart and systemd don't allow custom actions.
E.g. openvpn allows /etc/init.d/openvpn start vpn1 vpn2 ... vpnX

Do we specify which actions invoke-rc.d forwards and if so, which ones?


If invoke-rc.d intercepts and redirects the request to upstart (or
systemd), should update-rc.d do the same?

Say you run "update-rc.d <service> disable", should this disable only
the sysv init script, both, or only the upstart/systemd service?

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 21:20:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 21:20:15 GMT) Full text and rfc822 format available.

Message #234 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Russ Allbery <rra@debian.org>, 591791@bugs.debian.org
Cc: Michael Biebl <biebl@debian.org>, "Adam D. Barratt" <adam@adam-barratt.org.uk>, Tollef Fog Heen <tfheen@err.no>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 14:08:02 -0700
[Message part 1 (text/plain, inline)]
On Fri, Mar 16, 2012 at 01:07:08PM -0700, Russ Allbery wrote:

> This seems like a reasonable idea.  Steve, what do you think of having
> upstart provide such a shell library?  Then init scripts could contain
> code along the lines of:

>     if [ -r /lib/init/upstart.sh ] ; then
>         . /lib/init/upstart.sh
>         ignore_if_upstart
>     fi

> If upstart and systemd can agree on the same invocation semantics for the
> shell library, we could even provide a shell library that handled both and
> make this more generic.

I think this should all go in the lsb-base package (bug #661109).  That's
already a "standard" shell library for init scripts, which includes lots of
functions that aren't part of the LSB standard; I don't see a good reason to
contribute to a proliferation of shell libraries here.

As for making it generic, while I think there should be a similar function
for systemd, there needs to be some way for the init script to indicate
which init systems the package actually supports natively; we wouldn't want
ignore_if_not_sysvinit() for instance.

It also rubs me the wrong way to have the shell library exiting directly
from the init script.  I'd really prefer an interface such as
init_is_upstart() which leaves it open for the init script to handle some of
the mentioned corner cases - in particular, allowing for action=stop to DTRT
at all points during an upgrade.

> > Also, the proposal looks underspecified to me: What happens for other
> > actions, like stop/restart/reload/force-reload?

> My understanding is that calling those actions directly via the init
> script is not necessarily supported and invoke-rc.d should be used
> instead.  That should probably be spelled out explicitly.

Well, in the corner case of a package which calls 'invoke-rc.d restart' in
postinst, and upstart is running and we're upgrading to the first version of
the package which supports upstart, I see two options:

 - have the new version of the package call 'invoke-rc.d stop' in the
   preinst (before the upstart job is unpacked) so that the service is
   stopped via the init script.

 - have the new version of the package call '/etc/init.d/$service stop'
   explicitly in the postinst, since invoke-rc.d will now be looking at the
   upstart job instead.

I prefer the former because it respects policy's existing guidance about not
calling init scripts directly, but it also leaves a larger window when the
service will be down on upgrade - and the services that have bothered to use
'restart' in the postinst usually do so to prevent exactly this.

-- 
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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 21:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 21:27:04 GMT) Full text and rfc822 format available.

Message #239 received at 591791@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Steve Langasek <vorlon@debian.org>
Cc: Russ Allbery <rra@debian.org>, 591791@bugs.debian.org, "Adam D. Barratt" <adam@adam-barratt.org.uk>, Tollef Fog Heen <tfheen@err.no>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 22:16:59 +0100
[Message part 1 (text/plain, inline)]
On 16.03.2012 22:08, Steve Langasek wrote:
> On Fri, Mar 16, 2012 at 01:07:08PM -0700, Russ Allbery wrote:

>> If upstart and systemd can agree on the same invocation semantics for the
>> shell library, we could even provide a shell library that handled both and
>> make this more generic.
> 
> I think this should all go in the lsb-base package (bug #661109).  That's
> already a "standard" shell library for init scripts, which includes lots of
> functions that aren't part of the LSB standard; I don't see a good reason to
> contribute to a proliferation of shell libraries here.

Shipping it in lsb-base seems like a sensible idea.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 21:27:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 21:27:13 GMT) Full text and rfc822 format available.

Message #244 received at 591791@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Russ Allbery <rra@debian.org>
Cc: 591791@bugs.debian.org, Michael Biebl <biebl@debian.org>, "Adam D. Barratt" <adam@adam-barratt.org.uk>, Tollef Fog Heen <tfheen@err.no>
Subject: Re: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 16:19:15 -0500
Russ Allbery wrote:

> That seems like a feature, not a bug, in the case of configuration
> installed by Debian packages such as what's cited in this part of the
> thread.  If I have a policy rule that says not to run that init script, I
> mean it, and I don't want ifup running it anyway.

It's just plain not clear to me what policy-rc.d should and should not
be able to do.  The "do nothing and pretend you did something"
semantics, while they work ok in the context of post-installation
scripts that may or may not start the just-configured daemon, are
always going to feel a little weird in general because they break the
patterns

	start daemon &&
	interact with daemon

and

	stop daemon &&
	perform an action that uses a port normally used by daemon

and

	edit configuration file &&
	reload daemon configuration

Example for context:

  http://bugs.debian.org/445203#50

Which points to:

  http://bugs.debian.org/588085

> Jonathan Nieder <jrnieder@gmail.com> writes:

>> Another downside is that invoke-rc.d is Debian-specific.
>
> So are the network hooks under discussion.

I think the former is relevant and the latter isn't.  That may seem
odd, so let me mention a couple of examples of fallout.

 1. Suppose my (upstream) package wants to detect some network
    state and reconfigure itself when an interface goes up or down.
    So I provide a script that writes a file and runs
    "/etc/init.d/mydaemon reload" and say "Please run this when
    bringing up or down an interface".

    If policy mandates that ifup hooks use invoke-rc.d instead, my
    script cannot be used as-is in the Debian packaging.

 2. Suppose my (non Debian derived) operating system needs some
    infrastructure to bring up and down network interfaces,
    configuring them appropriately.  I notice ifupdown and like how
    it works and port it to my OS.

    Now if someone's (upstream) package notices that
    /etc/network/if-up.d is present and places a script there, all
    should be well, since I am using ifupdown, too.

    Except that that script might use invoke-rc.d, which is a
    Debian-specific interface my OS doesn't implement.  So I cannot
    use these hook scripts as-is, unless I _also_ adopt the
    invoke-rc.d interface from Debian.  The latter is somewhat
    ill-specified, so I (the hypothetical OS developer) am not going
    to do that.

In other words, yes, ifupdown hooks are Debian-specific, but they do
not have to be.  I would like the work I do on packaging software for
Debian to be useful for others when possible and have always been
reasonably happy with the efforts made in policy to support that (for
example by not including "debian" in the gcc triplet).

Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 21:30:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 21:30:08 GMT) Full text and rfc822 format available.

Message #249 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Michael Biebl <biebl@debian.org>
Cc: "Adam D. Barratt" <adam@adam-barratt.org.uk>, 591791@bugs.debian.org, Tollef Fog Heen <tfheen@err.no>, Russ Allbery <rra@debian.org>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 14:28:27 -0700
[Message part 1 (text/plain, inline)]
On Fri, Mar 16, 2012 at 09:25:17PM +0100, Michael Biebl wrote:
> > Well, it would be inappropriate to refuse to stop the service because
> > upstart was running.  The more likely outcome is that the init script
> > will not be able to find the running process, and will therefore exit 0
> > anyway as a no-op.  So I don't think there are any new requirements here
> > (which is why I didn't spell it out).

> If you kill the daemon from the sysv init script, upstart will just
> respawn it (if respawn is set) or mark it as failed.

Sorry, I was unclear.  What I meant was that, in the upgrade case where
upstart is already running but the service is not yet under control of
upstart, "/etc/init.d/$service stop" still needs to make sure it stops the
daemon if running.  The implementation should be careful to *not* kill
processes that were spawned via upstart; but in general that can be handled
by ensuring the upstart job doesn't create a pidfile that would confuse the
init script, and in the worst case it'd just be:

	stop)
		if init_is_upstart && status $service | grep -q start
		then
			exit 0
		fi
		[...]

Now alternatively, we could make it always an error to call
/etc/init.d/$service stop when there's an existing upstart job, and have
this command return non-zero just as for the start case.  But that requires
us to *guarantee* that the pre-upstart service is stopped *before* unpacking
the upstart-aware init script on the system, and that falls afoul of the
restart-in-postinst case.

> Personally, I would just prefer, if the shell library would forward the
> action requests to the native init system.

But this falls down horribly during the upgrade in a very error-prone
manner.

> Another problematic issue that comes to mind, is packages installing
> dhcp and ifup.d hooks which call /etc/init.d/<service> <start>

> From my recollection, there are at least a few that do this, the most
> prominent one is nfs-common.

I don't see any such hook script in nfs-common.  I see a few hooks that
call *reload*, which is always safe to call regardless of any invoke-rc.d
or runlevel policy.  But calling '/etc/init.d/$service start' directly from
a hook would be just as broken as calling it from a maintainer script,
because it bypasses said policy.

So this should be a non-issue.

-- 
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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 21:30:22 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 21:30:22 GMT) Full text and rfc822 format available.

Message #254 received at 591791@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Steve Langasek <vorlon@debian.org>
Cc: Russ Allbery <rra@debian.org>, 591791@bugs.debian.org, "Adam D. Barratt" <adam@adam-barratt.org.uk>, Tollef Fog Heen <tfheen@err.no>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 22:13:48 +0100
[Message part 1 (text/plain, inline)]
On 16.03.2012 22:08, Steve Langasek wrote:

> It also rubs me the wrong way to have the shell library exiting directly
> from the init script.  I'd really prefer an interface such as
> init_is_upstart() which leaves it open for the init script to handle some of
> the mentioned corner cases - in particular, allowing for action=stop to DTRT
> at all points during an upgrade.

Could you clarify the last point a bit? Where do you see a problem?

What I would really like to avoid is upstart and systemd specific
details creeping into the sysv init scripts.
sysvinit scripts are already horrible as is, adding more if ; then ;
else statements and various init system specific code will only make
that worse.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 21:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 21:51:17 GMT) Full text and rfc822 format available.

Message #259 received at 591791@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: 591791@bugs.debian.org
Cc: Steve Langasek <vorlon@debian.org>, "Adam D. Barratt" <adam@adam-barratt.org.uk>, Tollef Fog Heen <tfheen@err.no>, Russ Allbery <rra@debian.org>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 22:46:38 +0100
[Message part 1 (text/plain, inline)]
On 16.03.2012 22:05, Michael Biebl wrote:

> If invoke-rc.d intercepts and redirects the request to upstart (or
> systemd), should update-rc.d do the same?
> 
> Say you run "update-rc.d <service> disable", should this disable only
> the sysv init script, both, or only the upstart/systemd service?

The reason, why I brought this up, is this:

Say you run upstart/systemd and a you have a package which provides a
sysv init script foo, which you have disabled. On upgrades, invoke-rc.d
will respect and not run the service.
In version X, your packages starts shipping a upstart job file.
In this case invoke-rc.d will happily run the upstart job.
Do we require maintainers to preserve the on/off state of the service,
if they start shipping a native upstart/systemd job? What would be the
interface for that? Would this be a one-time migration or done on each
package upgrade? Do we "somehow" ensure the on/off state of the service
is kept consistent between the different init systems, so it doesn't
matter when I switch from sysvinit to upstart (or back again)?

Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 21:51:21 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 21:51:22 GMT) Full text and rfc822 format available.

Message #264 received at 591791@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Steve Langasek <vorlon@debian.org>
Cc: 591791@bugs.debian.org, Michael Biebl <biebl@debian.org>, "Adam D. Barratt" <adam@adam-barratt.org.uk>, Tollef Fog Heen <tfheen@err.no>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 14:46:51 -0700
Steve Langasek <vorlon@debian.org> writes:

> I think this should all go in the lsb-base package (bug #661109).
> That's already a "standard" shell library for init scripts, which
> includes lots of functions that aren't part of the LSB standard; I don't
> see a good reason to contribute to a proliferation of shell libraries
> here.

Agreed.

Ideally, we'd be able to refer to that in Policy, at least informatively.
(In general, I like for Policy to spell out what actually has to be done
technically rather than just saying "go use this package," but we can
advise using the package as well.)

> As for making it generic, while I think there should be a similar
> function for systemd, there needs to be some way for the init script to
> indicate which init systems the package actually supports natively; we
> wouldn't want ignore_if_not_sysvinit() for instance.

Good point.

> It also rubs me the wrong way to have the shell library exiting directly
> from the init script.  I'd really prefer an interface such as
> init_is_upstart() which leaves it open for the init script to handle
> some of the mentioned corner cases - in particular, allowing for
> action=stop to DTRT at all points during an upgrade.

Also a good point.  Exits inside libraries always have a bad odor.

However, what might argue for having multiple interfaces is Michael's
point about wanting a shell library that just forwards the actions to the
underlying init system.  In that case, you're going to always want to skip
the rest of the script, but you don't want init_is_upstart() as the
interface.

Maybe something like:

    init_is_upstart && { forward_to_upstart; exit $?; }
    init_is_systemd && { forward_to_systemd; exit $?; }

as the normal pattern for most init scripts, with the possibility left
open to do something more complex?

> Well, in the corner case of a package which calls 'invoke-rc.d restart'
> in postinst, and upstart is running and we're upgrading to the first
> version of the package which supports upstart, I see two options:

>  - have the new version of the package call 'invoke-rc.d stop' in the
>    preinst (before the upstart job is unpacked) so that the service is
>    stopped via the init script.

>  - have the new version of the package call '/etc/init.d/$service stop'
>    explicitly in the postinst, since invoke-rc.d will now be looking at the
>    upstart job instead.

> I prefer the former because it respects policy's existing guidance about
> not calling init scripts directly, but it also leaves a larger window
> when the service will be down on upgrade - and the services that have
> bothered to use 'restart' in the postinst usually do so to prevent
> exactly this.

I think we would have to do the former since, otherwise, wouldn't there be
two copies of the daemon running at the same time?  (Or, more likely, the
second wouldn't start, and then we might end up with no copies running
until upstart restarts it?)

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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 22:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 22:00:03 GMT) Full text and rfc822 format available.

Message #269 received at 591791@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Steve Langasek <vorlon@debian.org>, 591791@bugs.debian.org
Cc: "Adam D. Barratt" <adam@adam-barratt.org.uk>, Tollef Fog Heen <tfheen@err.no>, Russ Allbery <rra@debian.org>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 22:57:20 +0100
[Message part 1 (text/plain, inline)]
On 16.03.2012 22:28, Steve Langasek wrote:
> On Fri, Mar 16, 2012 at 09:25:17PM +0100, Michael Biebl wrote:
>>> Well, it would be inappropriate to refuse to stop the service because
>>> upstart was running.  The more likely outcome is that the init script
>>> will not be able to find the running process, and will therefore exit 0
>>> anyway as a no-op.  So I don't think there are any new requirements here
>>> (which is why I didn't spell it out).
> 
>> If you kill the daemon from the sysv init script, upstart will just
>> respawn it (if respawn is set) or mark it as failed.
> 
> Sorry, I was unclear.  What I meant was that, in the upgrade case where
> upstart is already running but the service is not yet under control of
> upstart, "/etc/init.d/$service stop" still needs to make sure it stops the
> daemon if running.  The implementation should be careful to *not* kill
> processes that were spawned via upstart; but in general that can be handled
> by ensuring the upstart job doesn't create a pidfile that would confuse the
> init script, and in the worst case it'd just be:
> 
> 	stop)
> 		if init_is_upstart && status $service | grep -q start
> 		then
> 			exit 0
> 		fi
> 		[...]
> 
> Now alternatively, we could make it always an error to call
> /etc/init.d/$service stop when there's an existing upstart job, and have
> this command return non-zero just as for the start case.  But that requires
> us to *guarantee* that the pre-upstart service is stopped *before* unpacking
> the upstart-aware init script on the system, and that falls afoul of the
> restart-in-postinst case.
> 
>> Personally, I would just prefer, if the shell library would forward the
>> action requests to the native init system.
> 
> But this falls down horribly during the upgrade in a very error-prone
> manner.
> 

Fwiw, this is a non-issue for systemd, as it treats sysv services and
native services alike. So during the upgrade, the old sysv based service
is stopped, systemd reloads the service definitions and sees that there
is a native one now, and starts the new, native one.

I acknowledge, that the upgrade case is a problem for upstart though.

I'm wondering if this couldn't be handled in invoke-rc.d though.
If upstart is running, and there is a native upstart job, which is not
running though, invoke-rc.d could just call /etc/init.d/foo stop

In postinst, when you run invoke-rc.d foo start, it would then start the
upstart job.
Wouldn't this cover this upgrade case?

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 22:00:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 22:00:05 GMT) Full text and rfc822 format available.

Message #274 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>, 591791@bugs.debian.org
Cc: Russ Allbery <rra@debian.org>, Michael Biebl <biebl@debian.org>, "Adam D. Barratt" <adam@adam-barratt.org.uk>, Tollef Fog Heen <tfheen@err.no>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 14:59:23 -0700
[Message part 1 (text/plain, inline)]
On Fri, Mar 16, 2012 at 04:19:15PM -0500, Jonathan Nieder wrote:
> Example for context:

>   http://bugs.debian.org/445203#50

> Which points to:

>   http://bugs.debian.org/588085

Given that there's a separate policy bug for this, I'm not sure what bearing
this has on the upstart discussion.  Could we perhaps take this to the other
bug?

-- 
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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 22:15:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 22:15:06 GMT) Full text and rfc822 format available.

Message #279 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Michael Biebl <biebl@debian.org>
Cc: 591791@bugs.debian.org, "Adam D. Barratt" <adam@adam-barratt.org.uk>, Tollef Fog Heen <tfheen@err.no>, Russ Allbery <rra@debian.org>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 15:12:35 -0700
[Message part 1 (text/plain, inline)]
On Fri, Mar 16, 2012 at 10:57:20PM +0100, Michael Biebl wrote:
> >> Personally, I would just prefer, if the shell library would forward the
> >> action requests to the native init system.

> > But this falls down horribly during the upgrade in a very error-prone
> > manner.

> Fwiw, this is a non-issue for systemd, as it treats sysv services and
> native services alike. So during the upgrade, the old sysv based service
> is stopped, systemd reloads the service definitions and sees that there
> is a native one now, and starts the new, native one.

By what mechanism is the new service started?  I don't see anything here
distinguishing systemd from upstart.  If the service is being stopped and
started via invoke-rc.d, you have all the same issues.  If systemd is
starting the service directly, that's a gross violation of policy.

> I'm wondering if this couldn't be handled in invoke-rc.d though.
> If upstart is running, and there is a native upstart job, which is not
> running though, invoke-rc.d could just call /etc/init.d/foo stop

> In postinst, when you run invoke-rc.d foo start, it would then start the
> upstart job.
> Wouldn't this cover this upgrade case?

It would; I just don't think invoke-rc.d is the right place for that
complexity to live.  For instance: if upstart is running, there's an upstart
job for foo, job foo is not running, and invoke-rc.d calls
/etc/init.d/foo stop as a fallback: how should invoke-rc.d handle the exit
code of /etc/init.d/foo?

All possible answers to that question are sufficiently irksome that I think
we should avoid putting the complexity in invoke-rc.d.

-- 
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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 16 Mar 2012 22:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 16 Mar 2012 22:36:03 GMT) Full text and rfc822 format available.

Message #284 received at 591791@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Steve Langasek <vorlon@debian.org>
Cc: 591791@bugs.debian.org, "Adam D. Barratt" <adam@adam-barratt.org.uk>, Tollef Fog Heen <tfheen@err.no>, Russ Allbery <rra@debian.org>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 23:33:26 +0100
[Message part 1 (text/plain, inline)]
On 16.03.2012 23:12, Steve Langasek wrote:
> On Fri, Mar 16, 2012 at 10:57:20PM +0100, Michael Biebl wrote:
>>>> Personally, I would just prefer, if the shell library would forward the
>>>> action requests to the native init system.
> 
>>> But this falls down horribly during the upgrade in a very error-prone
>>> manner.
> 
>> Fwiw, this is a non-issue for systemd, as it treats sysv services and
>> native services alike. So during the upgrade, the old sysv based service
>> is stopped, systemd reloads the service definitions and sees that there
>> is a native one now, and starts the new, native one.
> 
> By what mechanism is the new service started?  I don't see anything here
> distinguishing systemd from upstart.  If the service is being stopped and
> started via invoke-rc.d, you have all the same issues.  If systemd is
> starting the service directly, that's a gross violation of policy.

Under systemd, native and sysv service are all started and tracked by
systemd directly. The sysv based services are created on the fly. They
simplified look like
ExecStart=/etc/init.d/foo start
ExecStop=/etc/init.d/foo stop
etc.

The "invoke-rc.d foo stop" call is always forwarded to systemd, which
then calls "/etc/init.d/foo stop", reloads the service definitions
and "invoke-rc.d foo start" will then start the native one.

The big difference is, that the invoke-rc.d calls end up with systemd in
both cases and we let systemd call /etc/init.d/foo stop, instead of
doing it directly.

invoke-rc.d respects policy-rc.d, so I don't see a policy violation.

>> I'm wondering if this couldn't be handled in invoke-rc.d though.
>> If upstart is running, and there is a native upstart job, which is not
>> running though, invoke-rc.d could just call /etc/init.d/foo stop
> 
>> In postinst, when you run invoke-rc.d foo start, it would then start the
>> upstart job.
>> Wouldn't this cover this upgrade case?
> 
> It would; I just don't think invoke-rc.d is the right place for that
> complexity to live.  For instance: if upstart is running, there's an upstart
> job for foo, job foo is not running, and invoke-rc.d calls
> /etc/init.d/foo stop as a fallback: how should invoke-rc.d handle the exit
> code of /etc/init.d/foo?
> 
> All possible answers to that question are sufficiently irksome that I think
> we should avoid putting the complexity in invoke-rc.d.

invoke-rc.d already needs to be upstart aware, so this seems like the
right place to put this logic imho. Putting it in each and every sysv
init script on the other hand looks wrong to me.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Sat, 17 Mar 2012 00:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Fernando Lemos <fernandotcl@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 17 Mar 2012 00:27:03 GMT) Full text and rfc822 format available.

Message #289 received at 591791@bugs.debian.org (full text, mbox):

From: Fernando Lemos <fernandotcl@gmail.com>
To: 591791@bugs.debian.org
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 21:25:42 -0300
On Fri, Mar 16, 2012 at 5:07 PM, Russ Allbery <rra@debian.org> wrote:
> Michael Biebl <biebl@debian.org> writes:
>> How will "service" behave?
>
> service already handles upstart directly.  It presumably could and should
> be extended in an equivalent way to handle systemd.  I don't think that
> needs to be spelled out in Policy, since service is not an interface that
> (at least at the moment) is standardized in Policy.

FWIW, service doesn't handle well the situation where we're running
sysvinit but there's an upstart job installed:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636054

It's an implementation detail, though, I guess it could be fixed in time.

Regards,




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Sat, 17 Mar 2012 03:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 17 Mar 2012 03:57:03 GMT) Full text and rfc822 format available.

Message #294 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>, 591791@bugs.debian.org
Cc: Michael Biebl <biebl@debian.org>, "Adam D. Barratt" <adam@adam-barratt.org.uk>, Tollef Fog Heen <tfheen@err.no>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Fri, 16 Mar 2012 20:56:17 -0700
[Message part 1 (text/plain, inline)]
On Fri, Mar 16, 2012 at 03:14:18PM -0500, Jonathan Nieder wrote:

> By the way, the above example writes the path to initctl to the
> terminal when it is present, which I imagine is not intended.

Indeed not.  Updated example in the attached patch.

> [...]
> > Also, the proposal looks underspecified to me: What happens for other
> > actions, like stop/restart/reload/force-reload?

> Yes, I agree.  The example should be corrected to prevent the daemon
> from being started by the restart and force-reload actions.

This is difficult to include as part of a useful example if we expect the
init script to still handle the stop case, because the restart and
force-reload actions are so often implemented on top of start+stop.

-- 
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
[0001-Document-generic-and-upstart-specific-init-system-re.patch (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Sat, 17 Mar 2012 07:54:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tollef Fog Heen <tfheen@err.no>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 17 Mar 2012 07:54:03 GMT) Full text and rfc822 format available.

Message #299 received at 591791@bugs.debian.org (full text, mbox):

From: Tollef Fog Heen <tfheen@err.no>
To: Michael Biebl <biebl@debian.org>
Cc: 591791@bugs.debian.org, Steve Langasek <vorlon@debian.org>, "Adam D. Barratt" <adam@adam-barratt.org.uk>, Russ Allbery <rra@debian.org>
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Sat, 17 Mar 2012 08:50:50 +0100
]] Michael Biebl 

> Do we "somehow" ensure the on/off state of the service is kept
> consistent between the different init systems, so it doesn't matter
> when I switch from sysvinit to upstart (or back again)?

Yes, I think it's fairly obvious we need to keep the set of services
enabled/disabled regardless of init system.  I think it's the
responsibility of the init system to make sure that is actually true,
through a policy-defined mechanism which packages are required to use.

This does raise the interesting problem of how and where to do that
synchronisation.  I wonder if something like the emacsen-hooks mechanism
would make sense or if we should consider the rcN.d links to be
authoritative and it being up to the init system to make sure it
respects the state set by the symlinks.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Sat, 17 Mar 2012 08:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tollef Fog Heen <tfheen@err.no>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 17 Mar 2012 08:03:05 GMT) Full text and rfc822 format available.

Message #304 received at 591791@bugs.debian.org (full text, mbox):

From: Tollef Fog Heen <tfheen@err.no>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Russ Allbery <rra@debian.org>, 591791@bugs.debian.org, Michael Biebl <biebl@debian.org>, "Adam D. Barratt" <adam@adam-barratt.org.uk>
Subject: Re: [PATCH] Document generic and upstart-specific init-system requirements
Date: Sat, 17 Mar 2012 09:01:06 +0100
]] Jonathan Nieder 

> Russ Allbery wrote:
> 
> > That seems like a feature, not a bug, in the case of configuration
> > installed by Debian packages such as what's cited in this part of the
> > thread.  If I have a policy rule that says not to run that init script, I
> > mean it, and I don't want ifup running it anyway.
> 
> It's just plain not clear to me what policy-rc.d should and should not
> be able to do.  The "do nothing and pretend you did something"
> semantics, while they work ok in the context of post-installation
> scripts that may or may not start the just-configured daemon, are
> always going to feel a little weird in general because they break the
> patterns

They don't always work right in the context of postinst script either. A
fairly common request I'm hearing from people is «don't start the daemon
on initial installation (because we'll drop a configuration in place as
the next step and then start it)».  policy-rc.d can stop it from being
started at all, but it can't really know whether this is the initial
installation or not.  As Steve says, that's not really this bug, though.

[...]

> >> Another downside is that invoke-rc.d is Debian-specific.
> >
> > So are the network hooks under discussion.
> 
> I think the former is relevant and the latter isn't.  That may seem
> odd, so let me mention a couple of examples of fallout.

I'm not at all convinced invoke-rc.d is the right interface for this,
partially due to you easily ending up with cycles such as seen in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635777 where postfix
depends on network being up, but the network isn't considered up until
postfix has started.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 09 Apr 2012 23:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 09 Apr 2012 23:09:03 GMT) Full text and rfc822 format available.

Message #309 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Michael Biebl <biebl@debian.org>
Cc: 591791@bugs.debian.org
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Mon, 9 Apr 2012 16:07:55 -0700
[Message part 1 (text/plain, inline)]
On Fri, Mar 16, 2012 at 11:33:26PM +0100, Michael Biebl wrote:
> >> Fwiw, this is a non-issue for systemd, as it treats sysv services and
> >> native services alike. So during the upgrade, the old sysv based service
> >> is stopped, systemd reloads the service definitions and sees that there
> >> is a native one now, and starts the new, native one.

> > By what mechanism is the new service started?  I don't see anything here
> > distinguishing systemd from upstart.  If the service is being stopped and
> > started via invoke-rc.d, you have all the same issues.  If systemd is
> > starting the service directly, that's a gross violation of policy.

> Under systemd, native and sysv service are all started and tracked by
> systemd directly. The sysv based services are created on the fly. They
> simplified look like
> ExecStart=/etc/init.d/foo start
> ExecStop=/etc/init.d/foo stop
> etc.

> The "invoke-rc.d foo stop" call is always forwarded to systemd, which
> then calls "/etc/init.d/foo stop", reloads the service definitions
> and "invoke-rc.d foo start" will then start the native one.

So the invoke-rc.d code diverts all requests to systemd iff systemd is
running?  That seems like it should work ok for upgrades, yes, as in that
case any service started after systemd is booted will already be a systemd
unit.

Where does this invoke-rc.d code live, though?  I don't see it in the
sysvinit-provided invoke-rc.d implementation, and I don't see a separate
invoke-rc.d implementation shipped by any of the systemd binary packages.

> >> I'm wondering if this couldn't be handled in invoke-rc.d though.
> >> If upstart is running, and there is a native upstart job, which is not
> >> running though, invoke-rc.d could just call /etc/init.d/foo stop

> >> In postinst, when you run invoke-rc.d foo start, it would then start the
> >> upstart job.
> >> Wouldn't this cover this upgrade case?

> > It would; I just don't think invoke-rc.d is the right place for that
> > complexity to live.  For instance: if upstart is running, there's an upstart
> > job for foo, job foo is not running, and invoke-rc.d calls
> > /etc/init.d/foo stop as a fallback: how should invoke-rc.d handle the exit
> > code of /etc/init.d/foo?

> > All possible answers to that question are sufficiently irksome that I
> > think we should avoid putting the complexity in invoke-rc.d.

> invoke-rc.d already needs to be upstart aware, so this seems like the
> right place to put this logic imho. Putting it in each and every sysv
> init script on the other hand looks wrong to me.

You didn't actually answer the question I posed here.  How should
invoke-rc.d handle the exit code of /etc/init.d/foo to make this not suck in
the corner cases?

If you don't have an answer for how to make this reliable, I don't think
this aesthetic preference counts for much.

-- 
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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 09 Apr 2012 23:33:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 09 Apr 2012 23:33:02 GMT) Full text and rfc822 format available.

Message #314 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Michael Biebl <biebl@debian.org>
Cc: 591791@bugs.debian.org
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Mon, 9 Apr 2012 16:32:00 -0700
[Message part 1 (text/plain, inline)]
On Fri, Mar 16, 2012 at 10:05:32PM +0100, Michael Biebl wrote:
> >> What happens in maintainers scripts that call invoke-rc.d service start?
> >> Will they now suddenly all fail? How will invoke-rc.d behave when the
> >> package both installs a upstart job and sysv init script?

> > Doesn't this language already cover that?

> >    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.

> Seems I missed that, sorry. Yeah, invoke-rc.d forwarding the request to
> the native implementation looks fine in general.

> I think it would also make sense to specify, which actions are forwarded.
> I think policy mandates start/stop/restart/force-reload, status and
> reload are optional iirc. How would those be mapped to the corresponding
> upstart (or systemd) jobs.

I think answering that is out of scope for this policy bug.  It's obvious to
me that the requests *must* be mapped to the native interface, and the
implementation details of how that mapping is done are not interesting from
a policy perspective.

> What are we doing about custom actions?
> Contrary to sysvinit, upstart and systemd don't allow custom actions.
> E.g. openvpn allows /etc/init.d/openvpn start vpn1 vpn2 ... vpnX

> Do we specify which actions invoke-rc.d forwards and if so, which ones?

invoke-rc.d is an interface for maintainer scripts.  I don't see any reason
for a maintainer script to ever call custom actions, or for this to be
specified in policy if they do.

invoke-rc.d itself spits out a warning if you pass it a custom action.  So I
don't think this is something we should be worrying about.

> If invoke-rc.d intercepts and redirects the request to upstart (or
> systemd), should update-rc.d do the same?

No.  The update-rc.d policy interface is for managing a service's runlevel
configuration.  Those symlinks still need to be managed, regardless of
whether you're running upstart, to preserve compatibility if you reboot back
to sysvinit; and there is no corresponding action to be taken for upstart
because upstart scripts' runlevel declarations are part of the job
definition itself.

> Say you run "update-rc.d <service> disable", should this disable only
> the sysv init script, both, or only the upstart/systemd service?

'update-rc.d disable' is not a policy interface.  I think this is out of
scope for this bug.

But to answer the question, no, I don't think 'update-rc.d' is a sensible
tool to have as an admin-oriented, init-system-agnostic interface for
disabling services.  'service <foo> disable' would be much better.

-- 
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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 09 Apr 2012 23:57:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 09 Apr 2012 23:57:06 GMT) Full text and rfc822 format available.

Message #319 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Michael Biebl <biebl@debian.org>
Cc: 591791@bugs.debian.org
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Mon, 9 Apr 2012 16:55:38 -0700
[Message part 1 (text/plain, inline)]
Oh right, should've answered this mail together with the previous, sorry.

On Fri, Mar 16, 2012 at 10:46:38PM +0100, Michael Biebl wrote:
> > If invoke-rc.d intercepts and redirects the request to upstart (or
> > systemd), should update-rc.d do the same?

> > Say you run "update-rc.d <service> disable", should this disable only
> > the sysv init script, both, or only the upstart/systemd service?

> The reason, why I brought this up, is this:

> Say you run upstart/systemd and a you have a package which provides a
> sysv init script foo, which you have disabled. On upgrades, invoke-rc.d
> will respect and not run the service.
> In version X, your packages starts shipping a upstart job file.
> In this case invoke-rc.d will happily run the upstart job.
> Do we require maintainers to preserve the on/off state of the service,
> if they start shipping a native upstart/systemd job? What would be the
> interface for that? Would this be a one-time migration or done on each
> package upgrade? Do we "somehow" ensure the on/off state of the service
> is kept consistent between the different init systems, so it doesn't
> matter when I switch from sysvinit to upstart (or back again)?

I think preserving the on/off state of the service is a good idea, but I
also think it's premature to try to specify this in policy; AFAIK there's
currently no implementation for either upstart or systemd that does this.

There are really two subquestions here:

 - When a package adds support for other init systems, how does it ensure
   that the override status for the service is applied to all init systems?

 - How should an admin disable a service to make sure it's disabled for all
   init systems?

I think the answer to the second is definitely not 'update-rc.d disable'.

-- 
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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Tue, 10 Apr 2012 23:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 10 Apr 2012 23:09:04 GMT) Full text and rfc822 format available.

Message #324 received at 591791@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Steve Langasek <vorlon@debian.org>, 591791@bugs.debian.org
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Wed, 11 Apr 2012 01:08:24 +0200
[Message part 1 (text/plain, inline)]
On 10.04.2012 01:07, Steve Langasek wrote:
>>>> I'm wondering if this couldn't be handled in invoke-rc.d though.
>>>> If upstart is running, and there is a native upstart job, which is not
>>>> running though, invoke-rc.d could just call /etc/init.d/foo stop
> 
>>>> In postinst, when you run invoke-rc.d foo start, it would then start the
>>>> upstart job.
>>>> Wouldn't this cover this upgrade case?
> 
>>> It would; I just don't think invoke-rc.d is the right place for that
>>> complexity to live.  For instance: if upstart is running, there's an upstart
>>> job for foo, job foo is not running, and invoke-rc.d calls
>>> /etc/init.d/foo stop as a fallback: how should invoke-rc.d handle the exit
>>> code of /etc/init.d/foo?
> 
>>> All possible answers to that question are sufficiently irksome that I
>>> think we should avoid putting the complexity in invoke-rc.d.
> 
>> invoke-rc.d already needs to be upstart aware, so this seems like the
>> right place to put this logic imho. Putting it in each and every sysv
>> init script on the other hand looks wrong to me.
> 
> You didn't actually answer the question I posed here.  How should
> invoke-rc.d handle the exit code of /etc/init.d/foo to make this not suck in
> the corner cases?

What specific problems do you have in mind here. It's not really
possible to answer the question for some hypothetical issue.

> If you don't have an answer for how to make this reliable, I don't think
> this aesthetic preference counts for much.

I don't think code duplication and offloading the problem to each and
every maintainer is a astetic preference.
It's pretty obvious to me that pulling upstart specific details into
sysv init scripts is a bad idea, especially for package maintainers who
don't use upstart. I would much rather prefer a well tested
implementation in invoke-rc.d that is written and maintained by people
who know about upstart.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Fri, 04 May 2012 05:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 04 May 2012 05:39:03 GMT) Full text and rfc822 format available.

Message #329 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Michael Biebl <biebl@debian.org>, 591791@bugs.debian.org
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Thu, 3 May 2012 22:38:06 -0700
[Message part 1 (text/plain, inline)]
On Wed, Apr 11, 2012 at 01:08:24AM +0200, Michael Biebl wrote:
> >>> It would; I just don't think invoke-rc.d is the right place for that
> >>> complexity to live.  For instance: if upstart is running, there's an
> >>> upstart job for foo, job foo is not running, and invoke-rc.d calls
> >>> /etc/init.d/foo stop as a fallback: how should invoke-rc.d handle the
> >>> exit code of /etc/init.d/foo?

> >>> All possible answers to that question are sufficiently irksome that I
> >>> think we should avoid putting the complexity in invoke-rc.d.

> >> invoke-rc.d already needs to be upstart aware, so this seems like the
> >> right place to put this logic imho. Putting it in each and every sysv
> >> init script on the other hand looks wrong to me.

> > You didn't actually answer the question I posed here.  How should
> > invoke-rc.d handle the exit code of /etc/init.d/foo to make this not suck in
> > the corner cases?

> What specific problems do you have in mind here. It's not really
> possible to answer the question for some hypothetical issue.

Maintainer script calls invoke-rc.d foo stop.  invoke-rc.d looks for a 'foo'
upstart job and finds none running.  So it calls /etc/init.d/foo stop, which
fails.

Does invoke-rc.d return success because there was no upstart job running, or
failure because the init script failed?

-- 
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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 27 Aug 2012 17:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 27 Aug 2012 17:12:03 GMT) Full text and rfc822 format available.

Message #334 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: 591791@bugs.debian.org
Subject: Re: [PATCH] Document generic and upstart-specific init-system requirements
Date: Mon, 27 Aug 2012 10:10:50 -0700
[Message part 1 (text/plain, inline)]
user debian-policy@packages.debian.org
usertag 591791 seconded
thanks

If I understand the policy process correctly, the N=3 requirement for
patches includes the submitter; so with two other seconds, I think this is
ready to go.

-- 
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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 27 Aug 2012 18:12:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 27 Aug 2012 18:12:06 GMT) Full text and rfc822 format available.

Message #339 received at 591791@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Steve Langasek <vorlon@debian.org>
Cc: 591791@bugs.debian.org
Subject: Re: [PATCH] Document generic and upstart-specific init-system requirements
Date: Mon, 27 Aug 2012 11:10:53 -0700
Steve Langasek wrote:

> If I understand the policy process correctly, the N=3 requirement for
> patches includes the submitter; so with two other seconds, I think this is
> ready to go.

There was an objection from Michael Biebl and quite a bit of
discussion after those seconds which touched on important issues, and
I do not remember if the patch addressed them.  Would it be a bad idea
to refresh our memories by reposting the patch?

Sorry for the fuss,
Jonathan



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 27 Aug 2012 18:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 27 Aug 2012 18:39:03 GMT) Full text and rfc822 format available.

Message #344 received at 591791@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>, 591791@bugs.debian.org
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Mon, 27 Aug 2012 11:36:43 -0700
[Message part 1 (text/plain, inline)]
On Mon, Aug 27, 2012 at 11:10:53AM -0700, Jonathan Nieder wrote:

> > If I understand the policy process correctly, the N=3 requirement for
> > patches includes the submitter; so with two other seconds, I think this is
> > ready to go.

> There was an objection from Michael Biebl

True.  But when pressed on his aesthetic objections to this implementation,
he did not offer an alternative that did not suffer from wrong interface
semantics.  I don't think it's reasonable to hold this up indefinitely
waiting for a systemd user to design a solution he's happy with for upstart.

> and quite a bit of discussion after those seconds which touched on
> important issues

There has certainly been a lot of discussion, but most of it touched on
things which can/should be dealt with outside of policy.  Nobody has
suggested any concrete changes to the policy language in response to that
discussion.

The only post-seconding change was a bugfix to a code example included in
the patch.

>, and I do not remember if the patch addressed them.  Would it be a bad
> idea to refresh our memories by reposting the patch?

The current patch is the one at
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591791#294>.

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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 27 Aug 2012 18:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 27 Aug 2012 18:57:03 GMT) Full text and rfc822 format available.

Message #349 received at 591791@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: 591791@bugs.debian.org
Subject: Re: [PATCH] Document generic and upstart-specific init-system requirements
Date: Mon, 27 Aug 2012 11:53:14 -0700
[Message part 1 (text/plain, inline)]
Steve Langasek wrote:

> The current patch is the one at
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591791#294>.

Thanks!  Here's a copy for reference.  I take it from the rest
of your reply that you still second it.

(I haven't carefully reviewed the patch or later discussion yet
myself.)
[Document-generic-and-upstart-specific-init-system-re.patch (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 27 Aug 2012 20:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 27 Aug 2012 20:36:03 GMT) Full text and rfc822 format available.

Message #354 received at 591791@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 591791@bugs.debian.org
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Mon, 27 Aug 2012 13:35:05 -0700
Jonathan Nieder <jrnieder@gmail.com> writes:

> Thanks!  Here's a copy for reference.  I take it from the rest of your
> reply that you still second it.

> (I haven't carefully reviewed the patch or later discussion yet myself.)

I also still second it; I think it's time to get this into Policy, and we
can deal with any further refinements as additional work.  I don't think
there's anything about this that would force unreasonable behavior.

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



Added tag(s) pending; removed tag(s) patch. Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Mon, 03 Sep 2012 19:57:07 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#591791; Package debian-policy. (Mon, 03 Sep 2012 19:57:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 03 Sep 2012 19:57:09 GMT) Full text and rfc822 format available.

Message #361 received at 591791@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Steve Langasek <vorlon@debian.org>
Cc: 591791@bugs.debian.org
Subject: Re: Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
Date: Mon, 03 Sep 2012 12:56:38 -0700
Steve Langasek <vorlon@debian.org> writes:

> If I understand the policy process correctly, the N=3 requirement for
> patches includes the submitter; so with two other seconds, I think this
> is ready to go.

I have merged this patch for the next release.  Thanks!  While I think we
can improve this documentation as we go forward and will have additional
requirements we want to describe, I don't think there's anything harmful
in the current text and we can be incremental about this.  And it's what
packages are already doing to integrate with upstart, so we're describing
existing practice.

While it's less than ideal since it doesn't keep the init stuff together,
I moved the new section to the end of the chapter so as not to renumber
all the subsequent sections and break cross-references (in Lintian, for
example).  The general problem of maintaining cross-references is
something I want to tackle for the general DocBook rewrite, at which point
we'll also regroup all the init system stuff.

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



Reply sent to Russ Allbery <rra@debian.org>:
You have taken responsibility. (Wed, 19 Sep 2012 06:33:12 GMT) Full text and rfc822 format available.

Notification sent to Steve Langasek <vorlon@debian.org>:
Bug acknowledged by developer. (Wed, 19 Sep 2012 06:33:12 GMT) Full text and rfc822 format available.

Message #366 received at 591791-close@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 591791-close@bugs.debian.org
Subject: Bug#591791: fixed in debian-policy 3.9.4.0
Date: Wed, 19 Sep 2012 06:32:10 +0000
Source: debian-policy
Source-Version: 3.9.4.0

We believe that the bug you reported is fixed in the latest version of
debian-policy, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 591791@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Russ Allbery <rra@debian.org> (supplier of updated debian-policy package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Tue, 18 Sep 2012 21:35:36 -0700
Source: debian-policy
Binary: debian-policy
Architecture: source all
Version: 3.9.4.0
Distribution: unstable
Urgency: low
Maintainer: Debian Policy List <debian-policy@lists.debian.org>
Changed-By: Russ Allbery <rra@debian.org>
Description: 
 debian-policy - Debian Policy Manual and related documents
Closes: 374029 571776 591791 641153 654958 661816 661933 663918 670429 676561
Changes: 
 debian-policy (3.9.4.0) unstable; urgency=low
 .
   * build-arch and build-indep are now mandatory targets in debian/rules,
     implementing the Technical Committee ruling in #629385.  Wording
     review by Jonathan Nieder, Jakub Wilk, and Roger Leigh.
     (Closes: #374029)
   * Resynchronize the archive section list with ftp-master, adding tasks.
     Patch from Charles Plessy.  (Closes: #670429)
   * Policy: Copyright files must be encoded in UTF-8
     Wording: Russ Allbery <rra@debian.org>
     Seconded: Guillem Jover <guillem@debian.org>
     Seconded: Salvatore Bonaccorso <carnil@debian.org>
     Seconded: Simon McVittie <smcv@debian.org>
     Closes: #661933
   * Policy: Prohibit deprecated < and > relations
     Wording: Jakub Wilk <jwilk@debian.org>
     Seconded: Cyril Brulebois <kibi@debian.org>
     Seconded: Russ Allbery <rra@debian.org>
     Closes: #663918
   * Policy: Document the Built-Using field
     Wording: Charles Plessy <plessy@debian.org>
     Seconded: Russ Allbery <rra@debian.org>
     Seconded: Ansgar Burchardt <ansgar@debian.org>
     Closes: #641153
   * Policy: Document the Vcs-* fields
     Wording: Charles Plessy <plessy@debian.org>
     Wording: Jonathan Nieder <jrnieder@gmail.com>
     Seconded: Russ Allbery <rra@debian.org>
     Seconded: Charles Plessy <plessy@debian.org>
     Seconded: Guillem Jover <guillem@debian.org>
     Closes: #654958
   * Policy: Document restrictions on the use of /run for wheezy
     Wording: Roger Leigh <rleigh@debian.org>
     Seconded: Charles Plessy <plessy@debian.org>
     Seconded: Russ Allbery <rra@debian.org>
     Closes: #676561
   * Policy: Rewrite shared library dependency policy to document symbols
     Wording: Russ Allbery <rra@debian.org>
     Wording: Jonathan Nieder <jrnieder@gmail.com>
     Seconded: Raphaël Hertzog <hertzog@debian.org>
     Seconded: Julien Cristau <jcristau@debian.org>
     Closes: #571776
   * Policy: Document generic and upstart-specific init system requirements
     Wording: Steve Langasek <steve.langasek@canonical.com>
     Seconded: Russ Allbery <rra@debian.org>
     Seconded: Adam D. Barratt <adam@adam-barratt.org.uk>
     Closes: #591791
   * Policy: Rely on triggers instead of calling update-mime
     Wording: Charles Plessy <plessy@debian.org>
     Seconded: Russ Allbery <rra@debian.org>
     Seconded: Guillem Jover <guillem@debian.org>
     Closes: #661816
Checksums-Sha1: 
 c728495994bbdabc43055dfbedfd662bba5eb069 1518 debian-policy_3.9.4.0.dsc
 4c6bc2d0eb510313e1b4a0d2a932f4182ffe6f91 704838 debian-policy_3.9.4.0.tar.gz
 ac9ff5a5987343a736fb45af52d3178bae30d37e 2147892 debian-policy_3.9.4.0_all.deb
Checksums-Sha256: 
 c6dbad5976931268283c02903cf0dc3f3bb8dfc86710cab462e0e6c19aab1407 1518 debian-policy_3.9.4.0.dsc
 01ae1a19f7a251dd5c2b078736427f33f04c5f7e38308f874345f1e3e194dca5 704838 debian-policy_3.9.4.0.tar.gz
 c6e22f66e4cd38cbfac944bfebb41fa5608604326c6ecb9dbbd2213f5372ebbd 2147892 debian-policy_3.9.4.0_all.deb
Files: 
 e5683a409d1f740582e960158152b4ba 1518 doc optional debian-policy_3.9.4.0.dsc
 33eafa60a7c79f827adaa1bdb0cdcf83 704838 doc optional debian-policy_3.9.4.0.tar.gz
 2c5c278e5035e26489c3ae76f8c428d2 2147892 doc optional debian-policy_3.9.4.0_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJQWVEqAAoJEH2AMVxXNt51CfcH/226voYDWjhFjwJJh61d0XBI
3JRRYNqF7rZ59zl4kwEX+QFe/CoKnX1rEceBb9g3cCJ/AO6vU8Z+hhGnpr4eus1v
2BKhO4E8S6vqjtWfiXHIUmkIlGQeuxY3aBMWNZPgQzqEz9Skrc3aDel3zuuiKehE
fTk8Kse0hwTGp5h9nVaXawdZEPKFhcQT2NrhhTE/VmTHuC1EzUTcjOUDeu8tM2xy
r6Zjytz43qqvWinUQNYQXOtjt2zAVV0dw6T9nWcssXOSTD1EZLbfAbaJw9m1VG6G
B9BRhz5xs334/DktrgDw2gKjb4IF2tI3lIPRj12OuGErR+lChgZr4egrA+xyBwM=
=SP2c
-----END PGP SIGNATURE-----




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Mon, 03 Jun 2013 09:22:20 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 18 20:47:12 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.