Debian Bug report logs - #208010
Require init.d scripts comply with LSB

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: Martin Godisch <martin@godisch.de>

Date: Sun, 31 Aug 2003 11:18:02 UTC

Severity: wishlist

Merged with 181123

Found in versions 3.5.2.0, 3.6.1.0

Reply or subscribe to this bug.

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#208010; Package debian-policy. Full text and rfc822 format available.

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

From: Martin Godisch <martin@godisch.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: [PROPOSAL] init script LSB 1.3 compliance
Date: Sun, 31 Aug 2003 13:11:38 +0200
[Message part 1 (text/plain, inline)]
Package: debian-policy
Version: 3.6.1.0
Severity: wishlist
Tags: patch

This proposal aims to synchronize the Debian Policy, section 9.3, with
the LSB 1.3.0, chapter 24 [1]. Attached is a patch and the resulting
plain text for better reading.

Notes:

* I suggest merging the "reserved for..." items, but left them
  separated for the moment.
* What is log_failure_msg? Does this make sense on a Debian system?
  Replace it or skip it?

Kind regards,

Martin

[1] http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/iniscrptact.html
[policy.diff (text/plain, attachment)]
[policy.txt (text/plain, attachment)]
[Message part 4 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Andrew Suffield <asuffield@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Andrew Suffield <asuffield@debian.org>
To: 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Sun, 31 Aug 2003 14:08:03 +0100
[Message part 1 (text/plain, inline)]
On Sun, Aug 31, 2003 at 01:11:38PM +0200, Martin Godisch wrote:
> This proposal aims to synchronize the Debian Policy, section 9.3, with
> the LSB 1.3.0, chapter 24 [1]. Attached is a patch and the resulting
> plain text for better reading.

Objection. Why should our init scripts comply with the LSB?

Specifically, I object to the exit code stuff. I don't mind
documenting a 'status' target, so long as it is optional, but I see no
reason why we should change from our own scheme to this LSB one.

Note that the LSB exit codes are directly in conflict with our own -
they require the init script _fail_ if the program is removed but not
purged, while we require it silently do nothing and return
success. This proposal would therefore introduce bugs in most existing
init scripts.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to wouter@debian.org:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: wouter@debian.org
To: Martin Godisch <martin@godisch.de>, 208010@bugs.debian.org
Cc: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Sun, 31 Aug 2003 15:53:58 +0200
[Message part 1 (text/plain, inline)]
On Sun, Aug 31, 2003 at 01:11:38PM +0200, Martin Godisch wrote:
[...]
> +        In the case of init script commands other than <tt>status</tt> (i.e.,
> +        <tt>start</tt>, <tt>stop</tt>, <tt>restart</tt>, <tt>reload</tt>, and
> +        <tt>force-reload</tt>), the init script should return an exit status
> +        of zero if the action described by the argument has been successful.
> +        Otherwise, the init script should print an error message and return
> +        one of the following non-zero exit status codes.
> +        <taglist>
> +          <tag>1</tag>
> +          <item>generic or unspecified error,</item>
> +          <tag>2</tag>
> +          <item>invalid or excess argument(s),</item>
> +          <tag>3</tag>
> +          <item>unimplemented feature (for example, <tt>reload</tt>),</item>
> +          <tag>4</tag>
> +          <item>user had insufficient privilege,</item>
> +          <tag>5</tag>
> +          <item>program is not installed,</item>

Objection. There's no need for our packages to show the same
behavior as LSB packages for Debian to be LSB-compatible. Specifically,
there's no need to force our initscripts to exit with non-zero exit
code, since that would break a quite a few things.

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
  -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to wouter@debian.org:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

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

From: Martin Godisch <martin@godisch.de>
To: 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Sun, 31 Aug 2003 19:07:18 +0200
On Sun, Aug 31, 2003 at 14:08:03 +0100, Andrew Suffield wrote:

> > This proposal aims to synchronize the Debian Policy, section 9.3, with
> > the LSB 1.3.0, chapter 24 [1]. Attached is a patch and the resulting
> > plain text for better reading.
> 
> Objection. Why should our init scripts comply with the LSB?

Because it's a good thing to comply with the LSB when possible? Because
it's considered a bug [1] not to do so?

> Note that the LSB exit codes are directly in conflict with our own -
> they require the init script _fail_ if the program is removed but not
> purged, while we require it silently do nothing and return
> success. This proposal would therefore introduce bugs in most existing
> init scripts.

Obviously, because packages cannot change in the first place, they would
conflict with the current policy.

On Sun, Aug 31, 2003 at 15:53:58 +0200, wouter@debian.org wrote:

> Objection. There's no need for our packages to show the same
> behavior as LSB packages for Debian to be LSB-compatible.

Please explain.

> Specifically, there's no need to force our initscripts to exit with
> non-zero exit code, since that would break a quite a few things.

The only thing I'm aware of is when removed packages are purged.
invoke-rc.d can easily be patched to ignore exit code 5 from init
scripts. Try something like this with the current 0/1 exit codes...

Kind regards,

Martin

[1] http://people.debian.org/~ajt/sarge_rc_policy.txt (5.p)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@netexpress.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@netexpress.net>
To: Martin Godisch <martin@godisch.de>, 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Sun, 31 Aug 2003 12:09:41 -0500
[Message part 1 (text/plain, inline)]
On Sun, Aug 31, 2003 at 01:11:38PM +0200, Martin Godisch wrote:
> Package: debian-policy
> Version: 3.6.1.0
> Severity: wishlist
> Tags: patch

> This proposal aims to synchronize the Debian Policy, section 9.3, with
> the LSB 1.3.0, chapter 24 [1]. Attached is a patch and the resulting
> plain text for better reading.

> * I suggest merging the "reserved for..." items, but left them
>   separated for the moment.
> * What is log_failure_msg? Does this make sense on a Debian system?
>   Replace it or skip it?

> [1] http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/iniscrptact.html

Objection.  While it may be beneficial to include some aspects of the
LSB init script policy in our own, complete compliance would break
existing behavior and is unnecessarily complex.  There's no good reason
for Debian scripts to need to comply with the LSB, as Debian packages
are not LSB packages.

The LSB init script policy also says that all distro init script names
must be registered with LANANA, which is a total crock.

-- 
Steve Langasek
postmodern programmer
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@netexpress.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@netexpress.net>
To: Martin Godisch <martin@godisch.de>, 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Sun, 31 Aug 2003 12:56:24 -0500
[Message part 1 (text/plain, inline)]
On Sun, Aug 31, 2003 at 07:07:18PM +0200, Martin Godisch wrote:

> > > This proposal aims to synchronize the Debian Policy, section 9.3, with
> > > the LSB 1.3.0, chapter 24 [1]. Attached is a patch and the resulting
> > > plain text for better reading.

> > Objection. Why should our init scripts comply with the LSB?

> Because it's a good thing to comply with the LSB when possible? Because
> it's considered a bug [1] not to do so?

I think you've misunderstood the intent of that requirement.  The
requirement is that sarge be an LSB-compliant *host system*; the portion
of the LSB you're citing refers to how LSB packages *themselves* must
behave, it is not behavior that LSB packages must be able to depend on
from the underlying system.

-- 
Steve Langasek
postmodern programmer
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

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

From: Martin Godisch <martin@godisch.de>
To: 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Sun, 31 Aug 2003 20:29:02 +0200
On Sun, Aug 31, 2003 at 12:56:24 -0500, Steve Langasek wrote:

> > > Objection. Why should our init scripts comply with the LSB?
> 
> > Because it's a good thing to comply with the LSB when possible? Because
> > it's considered a bug [1] not to do so?
> 
> I think you've misunderstood the intent of that requirement.  The
> requirement is that sarge be an LSB-compliant *host system*; the portion
> of the LSB you're citing refers to how LSB packages *themselves* must
> behave, it is not behavior that LSB packages must be able to depend on
> from the underlying system.

o.k.

Another argument: The main advantage I see there is the finer
granularity of failure exit codes. The current practice is to exit with
0 or 1, you don't know, whether the service has been started if the
script exits successfully (package may be removed), and you don't know
what the failure is if it exits with 1, grep'ing the script output is
ugly and useless. Being able to distinguish failures using the script's
exit code is a clean way and would probably ease other tasks.

I'm willing to revert "exit 5" to our current practice if this is the
only hard argument against this proposal and if there is some interest
in such an updated proposal.

Kind regards,

Martin



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@netexpress.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@netexpress.net>
To: Martin Godisch <martin@godisch.de>, 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Sun, 31 Aug 2003 15:29:03 -0500
[Message part 1 (text/plain, inline)]
On Sun, Aug 31, 2003 at 08:29:02PM +0200, Martin Godisch wrote:
> On Sun, Aug 31, 2003 at 12:56:24 -0500, Steve Langasek wrote:
> 
> > > > Objection. Why should our init scripts comply with the LSB?
> > 
> > > Because it's a good thing to comply with the LSB when possible? Because
> > > it's considered a bug [1] not to do so?
> > 
> > I think you've misunderstood the intent of that requirement.  The
> > requirement is that sarge be an LSB-compliant *host system*; the portion
> > of the LSB you're citing refers to how LSB packages *themselves* must
> > behave, it is not behavior that LSB packages must be able to depend on
> > from the underlying system.

> Another argument: The main advantage I see there is the finer
> granularity of failure exit codes. The current practice is to exit with
> 0 or 1, you don't know, whether the service has been started if the
> script exits successfully (package may be removed), and you don't know
> what the failure is if it exits with 1, grep'ing the script output is
> ugly and useless. Being able to distinguish failures using the script's
> exit code is a clean way and would probably ease other tasks.

> I'm willing to revert "exit 5" to our current practice if this is the
> only hard argument against this proposal and if there is some interest
> in such an updated proposal.

Without the 'exit 5' portion, I think it represents a good target to
work towards; but it's a little too early to try to mandate these
fine-grained exit codes in policy.  I don't see anything in policy that
says you can't use most LSB exit codes from init scripts today -- if
there is, we should probably remove it -- so it's better to first try
implementing this in a few packages before making it part of policy.

-- 
Steve Langasek
postmodern programmer
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Andreas Barth <aba@not.so.argh.org>
To: 208010@bugs.debian.org
Cc: Martin Godisch <martin@godisch.de>
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Mon, 1 Sep 2003 09:35:46 +0200
* Steve Langasek (vorlon@netexpress.net) [030831 22:35]:
> Without the 'exit 5' portion, I think it represents a good target to
> work towards; but it's a little too early to try to mandate these
> fine-grained exit codes in policy.  I don't see anything in policy that
> says you can't use most LSB exit codes from init scripts today -- if
> there is, we should probably remove it -- so it's better to first try
> implementing this in a few packages before making it part of policy.

It would perhaps be good if the policy states exactly which exit codes
are allowed and which are preffered. That would make implementing
easier (perhaps this part should be in the developer reference, where
it would also help).

Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

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

From: Martin Godisch <martin@godisch.de>
To: 208010@bugs.debian.org
Subject: [PROPOSAL] init script LSB 1.3 compliance (revised)
Date: Mon, 1 Sep 2003 10:58:50 +0200
[Message part 1 (text/plain, inline)]
On Sun, Aug 31, 2003 at 13:11:38 +0200, Martin Godisch wrote:

Attached an updated proposal, without exit code 5 clause.

> Notes:
> 
> * I suggest merging the "reserved for..." items, but left them
>   separated for the moment.
> * What is log_failure_msg? Does this make sense on a Debian system?
>   Replace it or skip it?

Kind regards,

Martin
[policy.diff (text/plain, attachment)]
[Message part 3 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@srce.hr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Josip Rodin <joy@srce.hr>
To: Martin Godisch <martin@godisch.de>, 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance (revised)
Date: Mon, 1 Sep 2003 11:54:32 +0200
On Mon, Sep 01, 2003 at 10:58:50AM +0200, Martin Godisch wrote:
> --- debian-policy-3.6.1.0.orig/policy.sgml	2003-08-19 14:32:23.000000000 +0200
> +++ debian-policy-3.6.1.0/policy.sgml	2003-09-01 10:52:12.000000000 +0200
> +	      <tag><tt>status</tt></tag>
> +	      <item>print the current status of the service.</item>

> -	    The <tt>start</tt>, <tt>stop</tt>, <tt>restart</tt>, and
> -	    <tt>force-reload</tt> options should be supported by all
> -	    scripts in <file>/etc/init.d</file>, the <tt>reload</tt>
> -	    option is optional.
> +	    The <tt>start</tt>, <tt>stop</tt>, <tt>restart</tt>,
> +	    <tt>force-reload</tt>, and <tt>status</tt> options should
> +	    be supported by all scripts in <file>/etc/init.d</file>,
> +	    the <tt>reload</tt> option is optional.

This "status" needs to be made optional. We can't suddenly force
implementation of such an option in dozens of packages just because it
(is in LSB|sounds like a good idea).

> + Otherwise, the init script
> +	    should print an error message and return one of the following non-zero
> +	    exit status codes.

Rationale for the whole elaborate list, and in particular rationale why it
would be a bug if they weren't honored exactly to the spec?

> +	    All error messages should be printed on standard error. All
> +	    status messages should be printed on standard output.

This sounds like a nice idea. slapd for example logs critical errors to
syslog only and only if the loglevel is set high enough... however,
ramifications of adding this need more examination, for example how much
changes would this inflict on the packages.

> + (This does not prevent
> +	    scripts from calling the logging functions such as
> +	    <tt>log_failure_msg</tt>).

Parse error. Explain "log_failure_msg" first.

> * What is log_failure_msg? Does this make sense on a Debian system?
>   Replace it or skip it?

The policy process does not work by randomly throwing stuff into patches,
having them accepted, and then working out what the hell was it that we
just added.

-- 
     2. That which causes joy or happiness.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

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

From: Martin Godisch <martin@godisch.de>
To: 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance (revised)
Date: Mon, 1 Sep 2003 12:48:58 +0200
[Message part 1 (text/plain, inline)]
On Mon, Sep 01, 2003 at 11:54:32 +0200, Josip Rodin wrote:

> > +	    The <tt>start</tt>, <tt>stop</tt>, <tt>restart</tt>,
> > +	    <tt>force-reload</tt>, and <tt>status</tt> options should
> > +	    be supported by all scripts in <file>/etc/init.d</file>,
> > +	    the <tt>reload</tt> option is optional.
> 
> This "status" needs to be made optional. We can't suddenly force
> implementation of such an option in dozens of packages just because it
> (is in LSB|sounds like a good idea).

o.k.

> > + Otherwise, the init script
> > +	    should print an error message and return one of the following non-zero
> > +	    exit status codes.
> 
> Rationale for the whole elaborate list,

Following closely the wording of the LSB, as the rest of that policy
chapter already does. The parenthesized part can be skipped without
problems.

> and in particular rationale why it
> would be a bug if they weren't honored exactly to the spec?

What do you consider not honoring the spec in that case? exit 1 is still
present and wouldn't be a bug.

> > * What is log_failure_msg? Does this make sense on a Debian system?
> >   Replace it or skip it?
> 
> The policy process does not work by randomly throwing stuff into patches,
> having them accepted, and then working out what the hell was it that we
> just added.

There was no intention to get this accepted before discussing it, that's
why I put that note before. I let it there for the same reason as above,
the current section 9.3 follows very closely the text of the LSB, which
I don't consider that bad. I let it there so it can be replaced with
some Debian equivalent, which I'm not aware of. Since you are neither,
it's probably a good idea to remove it.

Kind regards,

Martin
[policy.diff (text/plain, attachment)]
[Message part 3 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@srce.hr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Josip Rodin <joy@srce.hr>
To: Martin Godisch <martin@godisch.de>, 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance (revised)
Date: Mon, 1 Sep 2003 13:17:20 +0200
On Mon, Sep 01, 2003 at 12:48:58PM +0200, Martin Godisch wrote:
> > > + Otherwise, the init script should print an error message and return
> > > +	    one of the following non-zero exit status codes.
> > 
> > Rationale for the whole elaborate list,
> 
> Following closely the wording of the LSB, as the rest of that policy
> chapter already does.

Actually it's the other way around really :)

Does LSB have a rationale for its list?

> > and in particular rationale why it
> > would be a bug if they weren't honored exactly to the spec?
> 
> What do you consider not honoring the spec in that case? exit 1 is still
> present and wouldn't be a bug.

That begs the question, why proclaim it if it's not going to be used?

> > > * What is log_failure_msg? Does this make sense on a Debian system?
> > >   Replace it or skip it?
> 
> I let it there so it can be replaced with some Debian equivalent, which
> I'm not aware of. Since you are neither, it's probably a good idea to
> remove it.

Maybe you should look into it and find out what it means? Sounds like an
abstraction for syslog logging.

-- 
     2. That which causes joy or happiness.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Stefan Gybas <sgybas@provective.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Stefan Gybas <sgybas@provective.de>
To: 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance (revised)
Date: Mon, 1 Sep 2003 17:11:37 +0200
[Message part 1 (text/plain, inline)]
On Mon, Sep 01, 2003 at 10:58:50AM +0200, Martin Godisch wrote:

> Attached an updated proposal, without exit code 5 clause.

I second this updated proposal.

I think status should be mandatory so it could be used by maintainer scripts
on package upgrades. This way, a service would not be started if it was not
running previously (see last month's thread "better make a standard for
/etc/*/*_not_to_be_run" at
http://lists.debian.org/debian-devel/2003/debian-devel-200308/msg02052.html
for the discussion about this).

Stefan
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Andrew Suffield <asuffield@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Andrew Suffield <asuffield@debian.org>
To: 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance (revised)
Date: Mon, 1 Sep 2003 16:56:27 +0100
[Message part 1 (text/plain, inline)]
On Mon, Sep 01, 2003 at 10:58:50AM +0200, Martin Godisch wrote:
> +	    In the case of init script commands other than <tt>status</tt> (i.e.,
> +	    <tt>start</tt>, <tt>stop</tt>, <tt>restart</tt>, <tt>reload</tt>, and
> +	    <tt>force-reload</tt>), the init script should return an exit status
> +	    of zero if the action described by the argument has been successful
> +	    or the package is removed but not purged. Otherwise, the init script
> +	    should print an error message and return one of the following non-zero
> +	    exit status codes.
> +	    <taglist>
> +	      <tag>1</tag>
> +	      <item>generic or unspecified error,</item>
> +	      <tag>2</tag>
> +	      <item>invalid or excess argument(s),</item>
> +	      <tag>3</tag>
> +	      <item>unimplemented feature (for example, <tt>reload</tt>),</item>
> +	      <tag>4</tag>
> +	      <item>user had insufficient privilege,</item>
> +	      <tag>5</tag>
> +	      <item>reserved for LSB use,</item>
> +	      <tag>6</tag>
> +	      <item>program is not configured,</item>
> +	      <tag>7</tag>
> +	      <item>program is not running,</item>
> +	      <tag>8-99</tag>
> +	      <item>reserved for future LSB use,</item>
> +	      <tag>100-149</tag>
> +	      <item>reserved for distribution use,</item>
> +	      <tag>150-199</tag>
> +	      <item>reserved for application use,</item>
> +	      <tag>200-254</tag>
> +	      <item>reserved.</item>
> +	    </taglist>
> +	    All error messages should be printed on standard error. All status
> +	    messages should be printed on standard output. (This does not prevent
> +	    scripts from calling the logging functions such as
> +	    <tt>log_failure_msg</tt>).
> +	  </p>

I think it's premature for the definition of the return values to be
under a "should" clause. Something like this would be more appropriate:


Otherwise, the init script should print an error message and return a
non-zero exit status code. Packages are encouraged to select return
codes based on the following list.


[When we have most packages in compliance with this, we can upgrade it
to a "should" clause again. This will likely be hastened if people
supply patches.]

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Andrew Suffield <asuffield@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Andrew Suffield <asuffield@debian.org>
To: 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance (revised)
Date: Mon, 1 Sep 2003 16:57:56 +0100
[Message part 1 (text/plain, inline)]
On Mon, Sep 01, 2003 at 05:11:37PM +0200, Stefan Gybas wrote:
> On Mon, Sep 01, 2003 at 10:58:50AM +0200, Martin Godisch wrote:
> 
> > Attached an updated proposal, without exit code 5 clause.
> 
> I second this updated proposal.
> 
> I think status should be mandatory so it could be used by maintainer scripts
> on package upgrades.

You can't make it mandatory before you implement it.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

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

From: Martin Godisch <martin@godisch.de>
To: 208010@bugs.debian.org
Subject: [PROPOSAL] init script LSB 1.3 compliance (revised iii)
Date: Mon, 1 Sep 2003 18:33:31 +0200
[Message part 1 (text/plain, inline)]
On Mon, Sep 01, 2003 at 16:56:27 +0100, Andrew Suffield wrote:

> Otherwise, the init script should print an error message and return a
> non-zero exit status code. Packages are encouraged to select return
> codes based on the following list.

Attached, thanks.

Kind regards,

Martin
[policy.diff (text/plain, attachment)]
[Message part 3 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Stefan Gybas <sgybas@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Stefan Gybas <sgybas@debian.org>
To: 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance (revised)
Date: Mon, 01 Sep 2003 20:00:07 +0200
Andrew Suffield wrote:

> You can't make it mandatory before you implement it.

I'll implement "status" for the init script and the changes to the 
maintainer scripts in my packages with the next upload. What else should 
I implement?

Stefan




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Henrique de Moraes Holschuh <hmh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Henrique de Moraes Holschuh <hmh@debian.org>
To: Stefan Gybas <sgybas@debian.org>, 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance (revised)
Date: Mon, 1 Sep 2003 19:25:22 -0300
On Mon, 01 Sep 2003, Stefan Gybas wrote:
> Andrew Suffield wrote:
> >You can't make it mandatory before you implement it.
> 
> I'll implement "status" for the init script and the changes to the 
> maintainer scripts in my packages with the next upload. What else should 
> I implement?

Tested patches against all init-script using packages to the BTS.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Colin Watson <cjwatson@debian.org>
To: Martin Godisch <martin@godisch.de>, 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance (revised)
Date: Tue, 2 Sep 2003 00:36:35 +0100
On Mon, Sep 01, 2003 at 10:58:50AM +0200, Martin Godisch wrote:
> --- debian-policy-3.6.1.0.orig/policy.sgml	2003-08-19 14:32:23.000000000 +0200
> +++ debian-policy-3.6.1.0/policy.sgml	2003-09-01 10:52:12.000000000 +0200
> @@ -5362,13 +5362,16 @@
>  	      <tag><tt>force-reload</tt></tag>
>  	      <item>cause the configuration to be reloaded if the
>  		  service supports this, otherwise restart the
> -		  service.</item>
> +		  service,</item>
> +
> +	      <tag><tt>status</tt></tag>
> +	      <item>print the current status of the service.</item>
>  	    </taglist>

I'd like to see a standard message format in section 9.4 ("Console
messages from init.d scripts"). It's probably appropriate to let init
scripts provide more detail if it's useful in particular cases, but
something like:

  Checking status of printer spooler: running.
  Checking status of OpenBSD Secure Shell server: stopped.

... as the first line of the output would be kind of nice.

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

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

From: Martin Godisch <martin@godisch.de>
To: 208010@bugs.debian.org
Subject: [PROPOSAL] init script LSB 1.3 compliance (revised iv)
Date: Tue, 2 Sep 2003 06:56:22 +0200
[Message part 1 (text/plain, inline)]
On Tue, Sep 02, 2003 at 00:36:35 +0100, Colin Watson wrote:

> I'd like to see a standard message format in section 9.4 ("Console
> messages from init.d scripts"). It's probably appropriate to let init
> scripts provide more detail if it's useful in particular cases, but
> something like:
> 
>   Checking status of printer spooler: running.
>   Checking status of OpenBSD Secure Shell server: stopped.
> 
> ... as the first line of the output would be kind of nice.

Attached, thanks.

Kind regards,

Martin
[policy.diff (text/plain, attachment)]
[Message part 3 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

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

From: Martin Godisch <martin@godisch.de>
To: 208010@bugs.debian.org
Subject: [PROPOSAL] init script LSB 1.3 compliance
Date: Wed, 3 Sep 2003 09:57:46 +0200
[Message part 1 (text/plain, inline)]
Hi,

Andrew, Wouter, Steve, do your objections still apply to the current
revision (attached below)?

Kind regards,

Martin
[policy.diff (text/plain, attachment)]
[Message part 3 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Andrew Suffield <asuffield@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Andrew Suffield <asuffield@debian.org>
To: 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Wed, 3 Sep 2003 10:19:42 +0100
[Message part 1 (text/plain, inline)]
This one seems okay. Seconded as amended.

On Wed, Sep 03, 2003 at 09:57:46AM +0200, Martin Godisch wrote:
> Andrew, Wouter, Steve, do your objections still apply to the current
> revision (attached below)?

> +++ debian-policy-3.6.1.0/policy.sgml	2003-09-02 06:53:48.000000000 +0200
> @@ -5362,13 +5362,16 @@
>  	      <tag><tt>force-reload</tt></tag>
>  	      <item>cause the configuration to be reloaded if the
>  		  service supports this, otherwise restart the
> -		  service.</item>
> +		  service,</item>
> +
> +	      <tag><tt>status</tt></tag>
> +	      <item>print the current status of the service.</item>
>  	    </taglist>
>  
>  	    The <tt>start</tt>, <tt>stop</tt>, <tt>restart</tt>, and
>  	    <tt>force-reload</tt> options should be supported by all
>  	    scripts in <file>/etc/init.d</file>, the <tt>reload</tt>
> -	    option is optional.
> +	    and <tt>status</tt> options are optional.
>  	  </p>
>  
>  	  <p>
> @@ -5421,6 +5424,67 @@
>  	  </p>
>  
>  	  <p>
> +	    In the case of init script commands other than <tt>status</tt>,
> +	    the init script should return an exit status of zero if the action
> +	    described by the argument has been successful or the package is
> +	    removed but not purged. Otherwise, the init script should print an
> +	    error message and return a non-zero exit status code. Packages are
> +	    encouraged to select return codes based on the following list.
> +	    <taglist>
> +	      <tag>1</tag>
> +	      <item>generic or unspecified error,</item>
> +	      <tag>2</tag>
> +	      <item>invalid or excess argument(s),</item>
> +	      <tag>3</tag>
> +	      <item>unimplemented feature (for example, <tt>reload</tt>),</item>
> +	      <tag>4</tag>
> +	      <item>user had insufficient privilege,</item>
> +	      <tag>5</tag>
> +	      <item>reserved for LSB use,</item>
> +	      <tag>6</tag>
> +	      <item>program is not configured,</item>
> +	      <tag>7</tag>
> +	      <item>program is not running,</item>
> +	      <tag>8-99</tag>
> +	      <item>reserved for future LSB use,</item>
> +	      <tag>100-149</tag>
> +	      <item>reserved for distribution use,</item>
> +	      <tag>150-199</tag>
> +	      <item>reserved for application use,</item>
> +	      <tag>200-254</tag>
> +	      <item>reserved.</item>
> +	    </taglist>
> +	    All error messages should be printed on standard error. All status
> +	    messages should be printed on standard output. (This does not
> +	    prevent scripts from calling logging functions.)
> +	  </p>
> +
> +	  <p>
> +	    If the status command is given, the init script should return the
> +	    following exit status codes.
> +	    <taglist>
> +	      <tag>0</tag>
> +	      <item>program is running or service is OK,</item>
> +	      <tag>1</tag>
> +	      <item>program is dead and /var/run pid file exists,</item>
> +	      <tag>2</tag>
> +	      <item>program is dead and /var/lock lock file exists,</item>
> +	      <tag>3</tag>
> +	      <item>program is stopped,</item>
> +	      <tag>4</tag>
> +	      <item>program or service status is unknown,</item>
> +	      <tag>5-99</tag>
> +	      <item>reserved for future LSB use,</item>
> +	      <tag>100-149</tag>
> +	      <item>reserved for distribution use,</item>
> +	      <tag>150-199</tag>
> +	      <item>reserved for application use,</item>
> +	      <tag>200-254</tag>
> +	      <item>reserved.</item>
> +	    </taglist>
> +	  </p>
> +
> +	  <p>
>  	    Often there are some variables in the <file>init.d</file>
>  	    scripts whose values control the behaviour of the scripts,
>  	    and which a system administrator is likely to want to
> @@ -5648,6 +5712,14 @@
>    . /etc/default/bind
>  fi
>  
> +help () {
> +  echo "Usage: /etc/init.d/bind {start|stop|restart|reload|force-reload}" >&2
> +}
> +
> +if [ "$2" ]; then
> +  help
> +  exit 2
> +fi
>  
>  case "$1" in
>  start)
> @@ -5676,10 +5748,13 @@
>    echo "."
>    ;;
> +status)
> +  echo "Checking status of domain name service: unknown."
> +  exit 4
> +  ;;
>  *)
> -  echo "Usage: /etc/init.d/bind " \
> -         " {start|stop|restart|reload|force-reload}" >&2
> -  exit 1
> +  help
> +  exit 2
>    ;;
>  esac
>  
> @@ -5923,6 +5998,24 @@
>  		daemon starting message.
>  	      </p>
>  	    </item>
> +
> +	    <item>
> +	      <p>When the daemon's status is queried</p>
> +
> +	      <p>
> +		When the <tt>status</tt> option is given, the first line of
> +		output should have the following format:
> +		<example compact="compact">
> +Checking status of <var>description</var>: <var>short-state</var>.
> +		</example>
> +		where <var>description</var> is the same as in the daemon
> +		starting message, and <var>short-state</var> is one of
> +		<tt>running</tt>, <tt>dead, pid file exists</tt>, <tt>dead,
> +		lock file exists</tt>, <tt>stopped</tt>, and <tt>unknown</tt>,
> +		corresponding to the status exit code. A more verbose status
> +		report may follow if appropriate.
> +	      </p>
> +	    </item>
>  	  </list>
>  	</p>
>        </sect>




-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Wouter Verhelst <wouter@grep.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Wouter Verhelst <wouter@grep.be>
To: Martin Godisch <martin@godisch.de>, 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Wed, 3 Sep 2003 17:44:49 +0200
[Message part 1 (text/plain, inline)]
On Wed, Sep 03, 2003 at 09:57:46AM +0200, Martin Godisch wrote:
> Hi,
> 
> Andrew, Wouter, Steve, do your objections still apply to the current
> revision (attached below)?

I'm still not comfortable with it, albeit in a different way.

[...]
>  	  <p>
> +	    In the case of init script commands other than <tt>status</tt>,
> +	    the init script should return an exit status of zero if the action
> +	    described by the argument has been successful or the package is
> +	    removed but not purged.

I'd like to see this rephrased. Does that mean '... the package is in
the process of being removed (but not purged)', or '... the package has
been removed but not purged'?

Given the discussion, I understand the latter is what's meant here, but
as written now, it's quite confusing.

> Otherwise, the init script should print an
> +	    error message and return a non-zero exit status code. Packages are
> +	    encouraged to select return codes based on the following list.
> +	    <taglist>
> +	      <tag>1</tag>
> +	      <item>generic or unspecified error,</item>
> +	      <tag>2</tag>
> +	      <item>invalid or excess argument(s),</item>
> +	      <tag>3</tag>
> +	      <item>unimplemented feature (for example, <tt>reload</tt>),</item>
> +	      <tag>4</tag>
> +	      <item>user had insufficient privilege,</item>
> +	      <tag>5</tag>
> +	      <item>reserved for LSB use,</item>
> +	      <tag>6</tag>
> +	      <item>program is not configured,</item>
> +	      <tag>7</tag>
> +	      <item>program is not running,</item>

This one will break removing and upgrading packages; dpkg checks the
exit code of maintainer scripts, assuming they failed if the exit code
was nonzero. Given the fact it is recommended by policy to use set -e in
maintainer scripts, dpkg will pick up this exit code and mark the
package as failed in the deconfiguration phase.  Either this requirement
should be removed, or policy should warn maintainers of that fact.

Other than that, I have no problem with the proposal as it currently
stands.

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
  -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

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

From: Martin Godisch <martin@godisch.de>
To: 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Wed, 3 Sep 2003 21:20:15 +0200
On Wed, Sep 03, 2003 at 17:44:49 +0200, Wouter Verhelst wrote:

> > +	    In the case of init script commands other than <tt>status</tt>,
> > +	    the init script should return an exit status of zero if the action
> > +	    described by the argument has been successful or the package is
> > +	    removed but not purged.
> 
> I'd like to see this rephrased. Does that mean '... the package is in
> the process of being removed (but not purged)', or '... the package has
> been removed but not purged'?
> 
> Given the discussion, I understand the latter is what's meant here, but
> as written now, it's quite confusing.

o.k.

> > Otherwise, the init script should print an
> > +	    error message and return a non-zero exit status code. Packages are
> > +	    encouraged to select return codes based on the following list.
> > +	    <taglist>
> > +	      <tag>1</tag>
> > +	      <item>generic or unspecified error,</item>
> > +	      <tag>2</tag>
> > +	      <item>invalid or excess argument(s),</item>
> > +	      <tag>3</tag>
> > +	      <item>unimplemented feature (for example, <tt>reload</tt>),</item>
> > +	      <tag>4</tag>
> > +	      <item>user had insufficient privilege,</item>
> > +	      <tag>5</tag>
> > +	      <item>reserved for LSB use,</item>
> > +	      <tag>6</tag>
> > +	      <item>program is not configured,</item>
> > +	      <tag>7</tag>
> > +	      <item>program is not running,</item>
> 
> This one will break removing and upgrading packages; dpkg checks the
> exit code of maintainer scripts, assuming they failed if the exit code
> was nonzero. Given the fact it is recommended by policy to use set -e in
> maintainer scripts, dpkg will pick up this exit code and mark the
> package as failed in the deconfiguration phase.  Either this requirement
> should be removed, or policy should warn maintainers of that fact.

In the deconfiguration phase "invoke-rc.d package stop" is run. What
error do you imagine here, which should not be reported to/by dpkg?

Kind regards,

Martin



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to David Coe <david@someotherplace.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: David Coe <david@someotherplace.org>
To: Martin Godisch <martin@godisch.de>
Cc: 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Wed, 03 Sep 2003 15:24:05 -0400
This is a nit, but I think 'status' should be in the example help text, too:

> echo "Usage: /etc/init.d/bind {start|stop|restart|reload|force-reload}" >&2

  echo "Usage: /etc/init.d/bind {start|stop|restart|reload|force-reload|status}" >&2



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

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

From: Martin Godisch <martin@godisch.de>
To: 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Wed, 3 Sep 2003 21:36:42 +0200
On Wed, Sep 03, 2003 at 15:24:05 -0400, David Coe wrote:

> This is a nit, but I think 'status' should be in the example help text, too:
> 
> > echo "Usage: /etc/init.d/bind {start|stop|restart|reload|force-reload}" >&2
> 
>   echo "Usage: /etc/init.d/bind {start|stop|restart|reload|force-reload|status}" >&2

This was intended, because "status" is more or less useless in the
example, and the help text was printed before Colin's suggestion.
But since "unknown" is now an official status, I'll add it. Thanks!

Kind regards,

Martin



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

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

From: Martin Godisch <martin@godisch.de>
To: 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Wed, 3 Sep 2003 22:01:53 +0200
On Wed, Sep 03, 2003 at 21:20:15 +0200, Martin Godisch wrote:

> > This one will break removing and upgrading packages; dpkg checks the
> > exit code of maintainer scripts, assuming they failed if the exit code
> > was nonzero. Given the fact it is recommended by policy to use set -e in
> > maintainer scripts, dpkg will pick up this exit code and mark the
> > package as failed in the deconfiguration phase.  Either this requirement
> > should be removed, or policy should warn maintainers of that fact.
> 
> In the deconfiguration phase "invoke-rc.d package stop" is run. What
> error do you imagine here, which should not be reported to/by dpkg?

There's an --oknodo missing in the stop target of the example, right?
In order to behave sensibly if the service isn't running?

Kind regards,

Martin



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Wouter Verhelst <wouter@grep.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Wouter Verhelst <wouter@grep.be>
To: Martin Godisch <martin@godisch.de>, 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Thu, 4 Sep 2003 01:36:06 +0200
[Message part 1 (text/plain, inline)]
On Wed, Sep 03, 2003 at 09:20:15PM +0200, Martin Godisch wrote:
> On Wed, Sep 03, 2003 at 17:44:49 +0200, Wouter Verhelst wrote:
> > > +	      <tag>7</tag>
> > > +	      <item>program is not running,</item>
> > 
> > This one will break removing and upgrading packages; dpkg checks the
> > exit code of maintainer scripts, assuming they failed if the exit code
> > was nonzero. Given the fact it is recommended by policy to use set -e in
> > maintainer scripts, dpkg will pick up this exit code and mark the
> > package as failed in the deconfiguration phase.  Either this requirement
> > should be removed, or policy should warn maintainers of that fact.
> 
> In the deconfiguration phase "invoke-rc.d package stop" is run. What
> error do you imagine here, which should not be reported to/by dpkg?

invoke-rc.d will pass the exit state on. According to invoke-rc.d's
manpage, a non-zero exit state "usually indicates a failure".

That isn't the case here; when the 'stop' target is invoked, and the
program wasn't running, a non-zero exit code is issued, even though the
status is actually what is requested.

Dpkg will consider any non-zero exit state as 'failed', and will stop
uninstalling the package.

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
  -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

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

From: Martin Godisch <martin@godisch.de>
To: 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Thu, 4 Sep 2003 05:11:57 +0200
On Thu, Sep 04, 2003 at 01:36:06 +0200, Wouter Verhelst wrote:

> > > > +	      <tag>7</tag>
> > > > +	      <item>program is not running,</item>
> > > 
> > > This one will break removing and upgrading packages; dpkg checks the
> > > exit code of maintainer scripts, assuming they failed if the exit code
> > > was nonzero. Given the fact it is recommended by policy to use set -e in
> > > maintainer scripts, dpkg will pick up this exit code and mark the
> > > package as failed in the deconfiguration phase.  Either this requirement
> > > should be removed, or policy should warn maintainers of that fact.
> > 
> > In the deconfiguration phase "invoke-rc.d package stop" is run. What
> > error do you imagine here, which should not be reported to/by dpkg?
> 
> invoke-rc.d will pass the exit state on. According to invoke-rc.d's
> manpage, a non-zero exit state "usually indicates a failure".
> 
> That isn't the case here; when the 'stop' target is invoked, and the
> program wasn't running, a non-zero exit code is issued, even though the
> status is actually what is requested.
> 
> Dpkg will consider any non-zero exit state as 'failed', and will stop
> uninstalling the package.

exit 7 should never occur in the stop target, this would contradict
policy anyway. If the init script exits with 7, say, in the reload
target, I think that would be o.k. I'll rephrase it. Thanks!

Kind regards,

Martin



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: Martin Godisch <martin@godisch.de>, 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Thu, 4 Sep 2003 17:33:17 +0200
  While I am in favor of improving the init scripts, I think the current
problem is that too many fail to implement policy properly. Augmenting
policy will not make things anyway better in that regard, though it can
be an insentive to fix them.

So if you ever change an init script to implement your proposal, please
check it really implement correctly what is mandated by current policy.

Comment below:

On Wed, Sep 03, 2003 at 09:57:46AM +0200, Martin Godisch wrote:
> --- debian-policy-3.6.1.0.orig/policy.sgml	2003-08-19 14:32:23.000000000 +0200
> +++ debian-policy-3.6.1.0/policy.sgml	2003-09-02 06:53:48.000000000 +0200
> @@ -5362,13 +5362,16 @@
>  	      <tag><tt>force-reload</tt></tag>
>  	      <item>cause the configuration to be reloaded if the
>  		  service supports this, otherwise restart the
> -		  service.</item>
> +		  service,</item>
> +
> +	      <tag><tt>status</tt></tag>
> +	      <item>print the current status of the service.</item>

This one can be very tricky to implement correctly, and may require more
code than what we would like in a config file.

A reference to the section below describing the output and return value
is needed.

> +	      <tag>8-99</tag>
> +	      <item>reserved for future LSB use,</item>


> +	      <tag>100-149</tag>
> +	      <item>reserved for distribution use,</item>
> +	      <tag>150-199</tag>
> +	      <item>reserved for application use,</item>
> +	      <tag>200-254</tag>
> +	      <item>reserved.</item>

Does the above make sense in the context of Debian Policy ? 

> +	    </taglist>
> +	    All error messages should be printed on standard error. All status
> +	    messages should be printed on standard output. (This does not
> +	    prevent scripts from calling logging functions.)
> +	  </p>

This paragraph should clarify what is a 'error message' as opposed to
a 'status message'

> +
> +	      <item>program or service status is unknown,</item>
> +	      <tag>5-99</tag>
> +	      <item>reserved for future LSB use,</item>
> +	      <tag>100-149</tag>
> +	      <item>reserved for distribution use,</item>
> +	      <tag>150-199</tag>
> +	      <item>reserved for application use,</item>
> +	      <tag>200-254</tag>
> +	      <item>reserved.</item>

Same remark as above.

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#208010; Package debian-policy. Full text and rfc822 format available.

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

From: Martin Godisch <martin@godisch.de>
To: 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Sat, 6 Sep 2003 21:52:34 +0200
On Thu, Sep 04, 2003 at 17:33:17 +0200, Bill Allombert wrote:

> > --- debian-policy-3.6.1.0.orig/policy.sgml	2003-08-19 14:32:23.000000000 +0200
> > +++ debian-policy-3.6.1.0/policy.sgml	2003-09-02 06:53:48.000000000 +0200
> > @@ -5362,13 +5362,16 @@
> >  	      <tag><tt>force-reload</tt></tag>
> >  	      <item>cause the configuration to be reloaded if the
> >  		  service supports this, otherwise restart the
> > -		  service.</item>
> > +		  service,</item>
> > +
> > +	      <tag><tt>status</tt></tag>
> > +	      <item>print the current status of the service.</item>
> 
> This one can be very tricky to implement correctly,

Yes, if the daemon doesn't support it itself and the maintainer is
willing to implement more than "unknown" in this case.

> and may require more code than what we would like in a config file.

It doesn't need to be in the init script. The init script may call some
helper program, which provides the necessary information.

> A reference to the section below describing the output and return value
> is needed.

"See next paragraph"? Not necessarily...

> > +	      <tag>8-99</tag>
> > +	      <item>reserved for future LSB use,</item>
> 
> > +	      <tag>100-149</tag>
> > +	      <item>reserved for distribution use,</item>
> > +	      <tag>150-199</tag>
> > +	      <item>reserved for application use,</item>
> > +	      <tag>200-254</tag>
> > +	      <item>reserved.</item>
> 
> Does the above make sense in the context of Debian Policy ? 

You think this can be better?

> > +	    </taglist>
> > +	    All error messages should be printed on standard error. All status
> > +	    messages should be printed on standard output. (This does not
> > +	    prevent scripts from calling logging functions.)
> > +	  </p>
> 
> This paragraph should clarify what is a 'error message' as opposed to
> a 'status message'

Possibly, what do you suggest?

Kind regards,

Martin



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: Martin Godisch <martin@godisch.de>, 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Mon, 8 Sep 2003 12:06:02 +0200
On Sat, Sep 06, 2003 at 09:52:34PM +0200, Martin Godisch wrote:
> On Thu, Sep 04, 2003 at 17:33:17 +0200, Bill Allombert wrote:
> "See next paragraph"? Not necessarily...
> 
> > > +	      <tag>8-99</tag>
> > > +	      <item>reserved for future LSB use,</item>
> > 
> > > +	      <tag>100-149</tag>
> > > +	      <item>reserved for distribution use,</item>
> > > +	      <tag>150-199</tag>
> > > +	      <item>reserved for application use,</item>
> > > +	      <tag>200-254</tag>
> > > +	      <item>reserved.</item>
> > 
> > Does the above make sense in the context of Debian Policy ? 
> 
> You think this can be better?

I think it can be removed completly. 

> > > +	    </taglist>
> > > +	    All error messages should be printed on standard error. All status
> > > +	    messages should be printed on standard output. (This does not
> > > +	    prevent scripts from calling logging functions.)
> > > +	  </p>
> > 
> > This paragraph should clarify what is a 'error message' as opposed to
> > a 'status message'
> 
> Possibly, what do you suggest?

This policy does not mandate any 'error message' than I am aware of, so:

   All messages mandated by policy should go to standard output. You should
   ensure that any other messages that can eventually be generated is send
   to standard error.

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#208010; Package debian-policy. Full text and rfc822 format available.

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

From: Martin Godisch <martin@godisch.de>
To: 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Mon, 8 Sep 2003 18:03:56 +0200
On Mon, Sep 08, 2003 at 12:06:02 +0200, Bill Allombert wrote:

> > > > [reserved exit codes]
> > > 
> > > Does the above make sense in the context of Debian Policy ? 
> > 
> > You think this can be better?
> 
> I think it can be removed completly. 

I disagree. "reserved" means "not recommended for usage" here, which
should be communicated somehow.

> > > This paragraph should clarify what is a 'error message' as opposed to
> > > a 'status message'
> > 
> > Possibly, what do you suggest?
> 
> This policy does not mandate any 'error message' than I am aware of, so:
> 
>    All messages mandated by policy should go to standard output. You should
>    ensure that any other messages that can eventually be generated is send
>    to standard error.

I question this definition. Examples: The bind example has a "usage"
message, which is printed to stderr. The extended status output is not
mandated by policy, it should go to stdout. Defining what an "error
message" is may cause more questions than it would answer. I may be
wrong and would like to hear other opinions.

Kind regards,

Martin



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: Martin Godisch <martin@godisch.de>, 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Tue, 9 Sep 2003 11:49:52 +0200
On Mon, Sep 08, 2003 at 06:03:56PM +0200, Martin Godisch wrote:
> On Mon, Sep 08, 2003 at 12:06:02 +0200, Bill Allombert wrote:
> 
> > > > > [reserved exit codes]
> > > > 
> > > > Does the above make sense in the context of Debian Policy ? 
> > > 
> > > You think this can be better?
> > 
> > I think it can be removed completly. 
> 
> I disagree. "reserved" means "not recommended for usage" here, which
> should be communicated somehow.

Policy recommend not to use them by explicitly listing thus that should
be used. That ought to be sufficient. Telling that some of them are
reserved by the LSB for LSB packages init files is not particularly
relevant to Debian policy. Or else explain what mean `reserved for
distribution' in ourt context.

> > This policy does not mandate any 'error message' than I am aware of, so:
> > 
> >    All messages mandated by policy should go to standard output. You should
> >    ensure that any other messages that can eventually be generated is send
> >    to standard error.
> 
> I question this definition. Examples: The bind example has a "usage"
> message, which is printed to stderr. The extended status output is not
> mandated by policy, it should go to stdout. Defining what an "error
> message" is may cause more questions than it would answer. 

OK, then go with
  All status messages mandated by policy should go to standard output.

We can hope people have sufficient sense to use stderr for error
messages.

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#208010; Package debian-policy. Full text and rfc822 format available.

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

From: Martin Godisch <martin@godisch.de>
To: 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Sat, 13 Sep 2003 08:35:08 +0200
On Tue, Sep 09, 2003 at 11:49:52 +0200, Bill Allombert wrote:

> Policy recommend not to use them by explicitly listing thus that should
> be used. That ought to be sufficient.

o.k.

>   All status messages mandated by policy should go to standard output.
> 
> We can hope people have sufficient sense to use stderr for error
> messages.

Yes, I think so. But now you suggest to add "mandated by policy" only,
what's the reason not to require other status messages to be sent to
standard output?

Kind regards,

Martin



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

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

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: Martin Godisch <martin@godisch.de>, 208010@bugs.debian.org
Subject: Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance
Date: Mon, 15 Sep 2003 15:14:18 +0200
On Sat, Sep 13, 2003 at 08:35:08AM +0200, Martin Godisch wrote:
> >   All status messages mandated by policy should go to standard output.
> > 
> > We can hope people have sufficient sense to use stderr for error
> > messages.
> 
> Yes, I think so. But now you suggest to add "mandated by policy" only,
> what's the reason not to require other status messages to be sent to
> standard output?

Because we don't need to write it down. These messages are not
mentionned in policy so policy has nothing to say about them. We rely
on common sense to send them to stdout the same way as error message to
stderr.

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#208010; Package debian-policy. Full text and rfc822 format available.

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

From: Martin Godisch <martin@godisch.de>
To: 208010@bugs.debian.org
Subject: [PROPOSAL] init script LSB 1.3 compliance (revised v)
Date: Mon, 15 Sep 2003 20:17:58 +0200
[policy.diff (text/plain, attachment)]
[Message part 2 (application/pgp-signature, inline)]

Owner recorded as Martin Godisch <martin@godisch.de>. Request was from Martin Godisch <martin@godisch.de> to control@bugs.debian.org. Full text and rfc822 format available.

Removed annotation that Bug was owned by Martin Godisch <martin@godisch.de>. Request was from Martin Godisch <martin@godisch.de> to control@bugs.debian.org. Full text and rfc822 format available.

Message sent on to Martin Godisch <martin@godisch.de>:
Bug#208010. Full text and rfc822 format available.

Message #170 received at 208010-submitter@bugs.debian.org (full text, mbox):

From: Thomas Hood <jdthood@aglu.demon.nl>
To: 208010-submitter@bugs.debian.org
Subject: Bug in patch
Date: Tue, 22 Jun 2004 16:05:56 +0200
The last patch submitted changes the example to do an "exit 2"
(after printing a Usage line) if the initscript method is not
implemented.  This should be an "exit 3".

I compared the patch with LSB 1.9.7-20040527 and found a number
of minor wording differences.
--
Thomas Hood




Merged 181123 208010. Request was from Thomas Hood <jdthood@aglu.demon.nl> to control@bugs.debian.org. Full text and rfc822 format available.

Tags removed: patch Request was from Manoj Srivastava <srivasta@golden-gryphon.com> to control@bugs.debian.org. Full text and rfc822 format available.

Tags removed: patch Request was from Manoj Srivastava <srivasta@golden-gryphon.com> to control@bugs.debian.org. Full text and rfc822 format available.

Changed Bug title to `Require init.d scripts comply with LSB' from `[PROPOSAL] init script LSB 1.3 compliance'. Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Mon, 17 Mar 2008 05:24:31 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#208010; Package debian-policy. (Thu, 29 Jul 2010 21:15:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 29 Jul 2010 21:15:07 GMT) Full text and rfc822 format available.

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

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: 208010@bugs.debian.org
Cc: 208010-subscribe@bugs.debian.org
Subject: Re: Require init.d scripts comply with LSB
Date: Thu, 29 Jul 2010 23:13:10 +0200
[Message part 1 (text/plain, inline)]
Hi folks.


I recently had a case which made me looking into this and Carsten Hey
pointed me to that specific bug report here.


Has there been any progress on this?

I mean we already use LSB init script headers for dependency based
booting...

Many scripts already have the status action (and then follow the exit
codes as implied by LSB).

In my opinion it would make sense, to quite closely follow
http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html in Debian.


One conflict is IIRC, that some exit status which would be reserved by
LSB is currently used by some scripts to denote a warning state.


Andrew mentioned this problem:
>Note that the LSB exit codes are directly in conflict with our own -
>they require the init script _fail_ if the program is removed but not
>purged, while we require it silently do nothing and return
>success. This proposal would therefore introduce bugs in most existing
>init scripts.


But I guess there are valid use cases in which it's very important that
we allow such scripts to fail then. My example:
Imagine having a dm-crypt secured system (or perhaps just one device or
so).
Imagine that a device is decrypted (a mapping is set up) and then
cryptsetup is removed (but not purged).

It's IMO not possible that cryptsetup simply closes all open dm-crypt
devices in it's prerm; if the device is still used (e.g. mounted)
closing would fail.

Now the initscript remains, most other files from cryptsetup are removed
and therefore the initscript is non-functional.

From a (meta)security point of view, it must be guaranteed, that if a
user says e.g. cryptdisks stop... either the dm-crypt devices are
cleanly stopped or he gets a warning and the script fails.
If we'd simply exit 0 the user would not notice, that the device is
still open, which is a potential security risk.

Guess that example pretty well shows why the exit 5 thingy could be
actually quite reasonable and (from a security point of view) necessary.


Cheers,
Chris.
[smime.p7s (application/x-pkcs7-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. (Thu, 29 Jul 2010 22:06:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 29 Jul 2010 22:06:06 GMT) Full text and rfc822 format available.

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

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: 208010@bugs.debian.org
Subject: Re: Require init.d scripts comply with LSB
Date: Fri, 30 Jul 2010 00:02:39 +0200
[Message part 1 (text/plain, inline)]
btw: Perhaps someone can explain me, when the Policy requests:
>These scripts should not fail obscurely when the configuration files
>remain but the package has been removed, as configuration files remain
>on the system after the package has been removed.

I mean are there any special technical reasons?

At least from a conceptual point of view it should be just the opposite
IMO.
I see no harm if such a script would fail, except nasty error messages.
And then a user can still decide to purge the package,.. and perhaps
save his personal customisations to the scripts (if any).

With dependency based boot it could even harm, that such scripts are
there but don't fail. Imagine that another script requires or suggests
it (either for start or stop) but the package is removed and the init
scripts still gives an "everything ok exit 0".


Cheers,
Chris.
[smime.p7s (application/x-pkcs7-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. (Thu, 29 Jul 2010 22:15:06 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>. (Thu, 29 Jul 2010 22:15:06 GMT) Full text and rfc822 format available.

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

From: Russ Allbery <rra@debian.org>
To: Christoph Anton Mitterer <calestyo@scientia.net>
Cc: 208010@bugs.debian.org
Subject: Re: Bug#208010: Require init.d scripts comply with LSB
Date: Thu, 29 Jul 2010 15:14:18 -0700
Christoph Anton Mitterer <calestyo@scientia.net> writes:

> btw: Perhaps someone can explain me, when the Policy requests:

>> These scripts should not fail obscurely when the configuration files
>> remain but the package has been removed, as configuration files remain
>> on the system after the package has been removed.

> I mean are there any special technical reasons?

> At least from a conceptual point of view it should be just the opposite
> IMO.  I see no harm if such a script would fail, except nasty error
> messages.  And then a user can still decide to purge the package,.. and
> perhaps save his personal customisations to the scripts (if any).

It's normal in Debian for init scripts to be left behind after packages
are removed, since Debian's package management system retains
configuration files by default (which includes init scripts).  This is
true across a wide variety of configuration files, and you'll find several
statements in Policy requiring that the system behave reasonably (not
produce lots of errors) in this state.

This is a design principle and design goal for Debian that goes beyond
just init scripts.  Having a package removed but not purged should not
cause errors, send the administrator mail from cron jobs, and so forth.

> With dependency based boot it could even harm, that such scripts are
> there but don't fail.

Package dependencies are not satisfied if the other package only has
config files installed, and package dependencies are the correct way of
solving this problem.

-- 
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#208010; Package debian-policy. (Thu, 29 Jul 2010 22:51:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 29 Jul 2010 22:51:13 GMT) Full text and rfc822 format available.

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

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Russ Allbery <rra@debian.org>
Cc: 208010@bugs.debian.org
Subject: Re: Bug#208010: Require init.d scripts comply with LSB
Date: Fri, 30 Jul 2010 00:46:53 +0200
[Message part 1 (text/plain, inline)]
Hey Russ...

On Thu, 2010-07-29 at 15:14 -0700, Russ Allbery wrote:
> It's normal in Debian for init scripts to be left behind after packages
> are removed, since Debian's package management system retains
> configuration files by default (which includes init scripts).  This is
> true across a wide variety of configuration files, and you'll find several
> statements in Policy requiring that the system behave reasonably (not
> produce lots of errors) in this state.
Yes, I've read that....


> This is a design principle and design goal for Debian that goes beyond
> just init scripts.  Having a package removed but not purged should not
> cause errors, send the administrator mail from cron jobs, and so forth.
I just wanted two things well three... ;)
1) Suggesting that it's a good idea to at least suggest usage of LSB
init script exit codes

2) At least let initscripts allow to fail (when the package is removed),
if there's strong reason for them (as e.g. in my dm-crypt example).

3) Suggest to reconsider the above for initscripts. It's absolutely
reasonable that left over configuration files shouldn't be allowed to
break anything. But IMO it does not in the case of initscripts. You just
get the warning message,.. but everything's fine.



> > With dependency based boot it could even harm, that such scripts are
> > there but don't fail.
> Package dependencies are not satisfied if the other package only has
> config files installed, and package dependencies are the correct way of
> solving this problem.
Uhm... ok...
Imagine a package using the status action from another facility to find
whether it's running or not.
If it runs, it starts its own daemon with different options e.g. to make
use of that daemon.
Now even if status is implemented,... the package of the initscript
might be removed (!purged)... we get exit 0 then. The script believes
the status would run. It does however not.


Cheers,
Chris :)


[smime.p7s (application/x-pkcs7-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. (Thu, 29 Jul 2010 23:00: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>. (Thu, 29 Jul 2010 23:00:02 GMT) Full text and rfc822 format available.

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

From: Russ Allbery <rra@debian.org>
To: Christoph Anton Mitterer <calestyo@scientia.net>
Cc: 208010@bugs.debian.org
Subject: Re: Bug#208010: Require init.d scripts comply with LSB
Date: Thu, 29 Jul 2010 15:58:20 -0700
Christoph Anton Mitterer <calestyo@scientia.net> writes:
> On Thu, 2010-07-29 at 15:14 -0700, Russ Allbery wrote:

>> This is a design principle and design goal for Debian that goes beyond
>> just init scripts.  Having a package removed but not purged should not
>> cause errors, send the administrator mail from cron jobs, and so forth.

> I just wanted two things well three... ;)
> 1) Suggesting that it's a good idea to at least suggest usage of LSB
> init script exit codes

I think LSB exit codes are by far the most controversial part of the LSB
proposal, are of dubious utility, and would mean declaring most of Debian
init scripts currently buggy.  I would not start here.  I think there are
other parts of LSB that can be more easily adopted, such as the header
format (already basically adopted and just requiring documentation) and
the init script actions.

I'm personally unconvinced that adopting the LSB exit code standard is
ever worth doing, but at the least, Policy is not the place to do it,
since it's not even close to existing practice in Debian.  This is one of
those places where, if this is something that the project wants to do, it
should be done in the packages first and then documented in Policy once
that work is mostly done, similar to how the init script headers have been
handled.

> 2) At least let initscripts allow to fail (when the package is removed),
> if there's strong reason for them (as e.g. in my dm-crypt example).

Do you have an example of a bug or user problem where the current Debian
Policy caused problems and would have been fixed by having a different
requirement?  I suspect this is only a theoretical issue.

> 3) Suggest to reconsider the above for initscripts. It's absolutely
> reasonable that left over configuration files shouldn't be allowed to
> break anything. But IMO it does not in the case of initscripts. You just
> get the warning message,.. but everything's fine.

I'm personally strongly opposed to changing this design principle in
Debian.  If the package is removed but not purged, the init script should
not report errors.  This is a common case in Debian, and I think it would
be a significant regression to have init scripts start producing errors in
this situation.

> Uhm... ok...

> Imagine a package using the status action from another facility to find
> whether it's running or not.

> If it runs, it starts its own daemon with different options e.g. to make
> use of that daemon.

That sounds like a rather dubious design.  Do you have some specific case
in mind where you'd want to do such a thing?

> Now even if status is implemented,... the package of the initscript
> might be removed (!purged)... we get exit 0 then. The script believes
> the status would run. It does however not.

I can see how this is a problem for status in particular, since status has
different exit code requirements than normal init script actions.  The
current Policy requirement:

    These scripts should not fail obscurely when the configuration files
    remain but the package has been removed, as configuration files remain
    on the system after the package has been removed.

is still reasonable, but the specific recommendation:

    Therefore, you should include a test statement at the top of the
    script, like this:

        test -f program-executed-later-in-script || exit 0

doesn't really make sense for status; it only makes sense for the init
script actions currently documented in Policy.  If we standardize the
status action, we should at the same time alter that advice to not
recommend an 0 exit status for the status action if the package is removed
but not purged.

Exiting with a non-zero status when the daemon isn't running isn't
"failing obscurely" and is fine under the current Policy requirement; it
just doesn't work with the Policy recommendation for how to implement that
requirement.

-- 
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#208010; Package debian-policy. (Thu, 29 Jul 2010 23:30:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 29 Jul 2010 23:30:08 GMT) Full text and rfc822 format available.

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

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Russ Allbery <rra@debian.org>
Cc: 208010@bugs.debian.org
Subject: Re: Bug#208010: Require init.d scripts comply with LSB
Date: Fri, 30 Jul 2010 01:27:21 +0200
[Message part 1 (text/plain, inline)]
On Thu, 2010-07-29 at 15:58 -0700, Russ Allbery wrote:
> I think LSB exit codes are by far the most controversial part of the LSB
> proposal, are of dubious utility,
What are the arguments against them?


> and would mean declaring most of Debian
> init scripts currently buggy.
That makes ever introducing such changes extremely difficult, even if
the are worth it (as the dependency based booting proved ;) )


> I'm personally unconvinced that adopting the LSB exit code standard is
> ever worth doing, but at the least, Policy is not the place to do it,
> since it's not even close to existing practice in Debian.  This is one of
> those places where, if this is something that the project wants to do, it
> should be done in the packages first and then documented in Policy once
> that work is mostly done, similar to how the init script headers have been
> handled.
Fair argument.

Is there a "mechanism" in Debian... e.g. something like a staging area,
where one could specify such stuff (or things like the dependency based
booting) in order to clearly tell everybody "this is the future,...
start adopting it" but not making their packages immediately break the
policy?
I mean just by "this makes things better some day" it's hard to convince
maintainers ;)


> > 2) At least let initscripts allow to fail (when the package is removed),
> > if there's strong reason for them (as e.g. in my dm-crypt example).
> Do you have an example of a bug or user problem where the current Debian
> Policy caused problems and would have been fixed by having a different
> requirement?  I suspect this is only a theoretical issue.
No... see the example with cryptsetup I've described above, where
following the policy would open a security problem.


> > 3) Suggest to reconsider the above for initscripts. It's absolutely
> > reasonable that left over configuration files shouldn't be allowed to
> > break anything. But IMO it does not in the case of initscripts. You just
> > get the warning message,.. but everything's fine.
> 
> I'm personally strongly opposed to changing this design principle in
> Debian.  If the package is removed but not purged, the init script should
> not report errors.  This is a common case in Debian, and I think it would
> be a significant regression to have init scripts start producing errors in
> this situation.
Well that was just a suggestion :) ... anyway... can you tell examples
where this would really produce errors (I mean except some messages to
that initscript foo has failed).


> > Imagine a package using the status action from another facility to find
> > whether it's running or not.
> 
> > If it runs, it starts its own daemon with different options e.g. to make
> > use of that daemon.
> 
> That sounds like a rather dubious design.  Do you have some specific case
> in mind where you'd want to do such a thing?
At this point it was rather theoretical thinking on what could
happen,... but I have actually a case:
My long term wish (and it will be a very very stony way) is to package
dCache... this make use of different other daemons e.g. a database
(postgresl, or others) and some message brokers (activeMQ, an internal
system)... etc.
Require-start or should-start is AFAIU not the solution to start them,
because one wants to be able to select alternatives.
And on needs to tell the actual deamon which is used. Therefore, testing
with status could be a nice solution,... or at least I cannot think of
any better right now ;)


> > Now even if status is implemented,... the package of the initscript
> > might be removed (!purged)... we get exit 0 then. The script believes
> > the status would run. It does however not.
> 
> I can see how this is a problem for status in particular, since status has
> different exit code requirements than normal init script actions.  The
> current Policy requirement:
> 
>     These scripts should not fail obscurely when the configuration files
>     remain but the package has been removed, as configuration files remain
>     on the system after the package has been removed.
> 
> is still reasonable, but the specific recommendation:
> 
>     Therefore, you should include a test statement at the top of the
>     script, like this:
> 
>         test -f program-executed-later-in-script || exit 0
> 
> doesn't really make sense for status; it only makes sense for the init
> script actions currently documented in Policy.  If we standardize the
> status action, we should at the same time alter that advice to not
> recommend an 0 exit status for the status action if the package is removed
> but not purged.
Which would probably be 5 then :D



> Exiting with a non-zero status when the daemon isn't running isn't
> "failing obscurely" and is fine under the current Policy requirement; it
> just doesn't work with the Policy recommendation for how to implement that
> requirement.
Uhm... what exactly do you mean? :-O


Best wishes,
Chris. :)

[smime.p7s (application/x-pkcs7-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. (Thu, 29 Jul 2010 23:54:06 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>. (Thu, 29 Jul 2010 23:54:06 GMT) Full text and rfc822 format available.

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

From: Russ Allbery <rra@debian.org>
To: Christoph Anton Mitterer <calestyo@scientia.net>
Cc: 208010@bugs.debian.org
Subject: Re: Bug#208010: Require init.d scripts comply with LSB
Date: Thu, 29 Jul 2010 16:51:40 -0700
Christoph Anton Mitterer <calestyo@scientia.net> writes:
> On Thu, 2010-07-29 at 15:58 -0700, Russ Allbery wrote:

>> I think LSB exit codes are by far the most controversial part of the LSB
>> proposal, are of dubious utility,

> What are the arguments against them?

Please see the bug log for this bug.  It was the first thing that everyone
objected to.

Also, as Joy points out in:

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208010#52

this is backwards.  What are the arguments *in favor* of them?  Our
default should be to not put requirements on packages in Policy; Policy is
already long and complicated.  We should only be putting requirements in
packages when doing so solves a concrete interoperability or
standardization need.

Certainly, one argument in favor is "so that we comply with LSB."  But I
don't think that is, by itself, sufficient justification to change all the
init scripts in Debian, particularly given that there's a reasonable
chance that we'll be moving away from init scripts, at least in part, to
some other system in the relatively near future given all the other
drawbacks and deficiencies of the init script system.

> That makes ever introducing such changes extremely difficult, even if
> the are worth it (as the dependency based booting proved ;) )

That's correct.  It's very difficult, and requires a high bar, to
introduce change into Debian that requires all package maintainers of a
particular type of package, such as ones with init scripts, to change
their packages.  I think this is a feature, not a bug.  We would be asking
a lot of people to do a lot of work, and we need to be very clear that
it's worth it.

The LSB script headers solved a real problem and let us introduce a better
boot system, and the project considered that worth it.  It's not at all
clear to me that the init script status codes have a similar compelling
use case.

I'm more of an advocate of status, since status is very useful for
configuration management tools such as Puppet and avoids duplicating init
script information to figure out whether a daemon is currently running.

> Is there a "mechanism" in Debian... e.g. something like a staging area,
> where one could specify such stuff (or things like the dependency based
> booting) in order to clearly tell everybody "this is the future,...
> start adopting it" but not making their packages immediately break the
> policy?

I think that's the goal of the DEP process:

    http://dep.debian.net/

>> Do you have an example of a bug or user problem where the current
>> Debian Policy caused problems and would have been fixed by having a
>> different requirement?  I suspect this is only a theoretical issue.

> No... see the example with cryptsetup I've described above, where
> following the policy would open a security problem.

I don't agree that your example has proven that.  It looks theoretical to
me, and a stretch to call that a security issue in Debian (as opposed to a
misunderstanding by the user of what's required to maintain a consistent
system).  If the user wants to have encrypted devices, they need to not
remove the packages that handle device encryption.

>> I'm personally strongly opposed to changing this design principle in
>> Debian.  If the package is removed but not purged, the init script
>> should not report errors.  This is a common case in Debian, and I think
>> it would be a significant regression to have init scripts start
>> producing errors in this situation.

> Well that was just a suggestion :) ... anyway... can you tell examples
> where this would really produce errors (I mean except some messages to
> that initscript foo has failed).

You're excepting something that I'm not willing to accept.  If the package
is removed but not purged, the init scripts should not be producing
errors.

> My long term wish (and it will be a very very stony way) is to package
> dCache... this make use of different other daemons e.g. a database
> (postgresl, or others) and some message brokers (activeMQ, an internal
> system)... etc.

> Require-start or should-start is AFAIU not the solution to start them,
> because one wants to be able to select alternatives.

> And on needs to tell the actual deamon which is used. Therefore, testing
> with status could be a nice solution,... or at least I cannot think of
> any better right now ;)

I would prompt the user with debconf to ask them which backends they want
to use.  Assuming that they want to use a backend just because a package
is installed and running on the system is a bad assumption, I think,
although it's a reasonable way to set the default for the debconf
question.

>> I can see how this is a problem for status in particular, since status
>> has different exit code requirements than normal init script actions.
>> The current Policy requirement:

>>     These scripts should not fail obscurely when the configuration files
>>     remain but the package has been removed, as configuration files remain
>>     on the system after the package has been removed.

>> is still reasonable, but the specific recommendation:

>>     Therefore, you should include a test statement at the top of the
>>     script, like this:

>>         test -f program-executed-later-in-script || exit 0

>> doesn't really make sense for status; it only makes sense for the init
>> script actions currently documented in Policy.  If we standardize the
>> status action, we should at the same time alter that advice to not
>> recommend an 0 exit status for the status action if the package is
>> removed but not purged.

> Which would probably be 5 then :D

I personally don't see any compelling reason to say that.  I don't object
to people using exit code 5, but I don't see any benefit to doing that
work personally.

>> Exiting with a non-zero status when the daemon isn't running isn't
>> "failing obscurely" and is fine under the current Policy requirement;
>> it just doesn't work with the Policy recommendation for how to
>> implement that requirement.

> Uhm... what exactly do you mean? :-O

I mean that your example doesn't violate the intent of the current policy,
just fails because Policy was written without considering a status action.
The intent of the Policy requirement is that actions like start and stop
not fail when the package is removed but not purged, not that status
always return success in that case.

-- 
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#208010; Package debian-policy. (Fri, 30 Jul 2010 10:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 30 Jul 2010 10:42:03 GMT) Full text and rfc822 format available.

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

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Russ Allbery <rra@debian.org>
Cc: <208010@bugs.debian.org>
Subject: Re: Bug#208010: Require init.d scripts comply with LSB
Date: Fri, 30 Jul 2010 10:39:28 +0000
On Thu, 29 Jul 2010 16:51:40 -0700, Russ Allbery <rra@debian.org> wrote:
> Please see the bug log for this bug.  It was the first thing that
everyone
> objected to.
I read that... and seen no real technical arguments,... just "it would
break things"... and the "argument" that many packages would need to
support this than and to "a lot" of work...


> What are the arguments *in favor* of them?
- Finer grained control on what happens.
- And IMO it's always a good idea to align to reasonable standards (which
don't mean that I support all aspects of LSB ;) )...
- It makes us more homogeneous with other distros or upstream packages
whose intscripts follow LSB... less need to patch.. etc. 


> Our
> default should be to not put requirements on packages in Policy; Policy
is
> already long and complicated.  We should only be putting requirements in
> packages when doing so solves a concrete interoperability or
> standardization need.
But as I understood,.. it would not work here, to slowly convince
maintainers to use the LSB way here, and then - once the majority did -
adapt the policy (as it happens with dependency based booting). Because
e.g. the exit 5 thingy already conflicts with the policy (well ok it only
says "should" ;) ).


> Certainly, one argument in favor is "so that we comply with LSB."  But I
> don't think that is, by itself, sufficient justification
I agree here with you,.. that alone wouldn't suffice...
But I think the finer grained info from the exit statuses is really quite
nicely usable and the same holds true for the status action :)

> to change all the
> init scripts in Debian, particularly given that there's a reasonable
> chance that we'll be moving away from init scripts, at least in part, to
> some other system in the relatively near future given all the other
> drawbacks and deficiencies of the init script system.
That's actually a good point,... but isn't that also a long term thingy?
:D


> That's correct.  It's very difficult, and requires a high bar, to
> introduce change into Debian that requires all package maintainers of a
> particular type of package, such as ones with init scripts, to change
> their packages.  I think this is a feature, not a bug.  We would be
asking
> a lot of people to do a lot of work, and we need to be very clear that
> it's worth it.
Well again,... I don't mean to tell you that I'm smarter than everybody
else,... if we would move towards more conformance here with LSB (I mean
status action, exit status codes) I'd consider it a good change,... but the
world won't stop turning if not.

I believe however, that the section which says initscripts must not fail,
when the package is removed can be a real problem (cryptsetup example).
And even if there is not strong problem,... it's still unlogical IMHO to
not fail then.
If I do e.g. /etc/init.d/service start ... I expect it to be started and
if that didn't work for what ever reason I'd expect an error.
Regardless whether the package is installed or removed :)


> The LSB script headers solved a real problem and let us introduce a
better
> boot system, and the project considered that worth it.  It's not at all
> clear to me that the init script status codes have a similar compelling
> use case.
Definitely not that big influence,... IMO it's rather a small but nice
improvement.

 
> I'm more of an advocate of status, since status is very useful for
> configuration management tools such as Puppet and avoids duplicating
init
> script information to figure out whether a daemon is currently running.
I also like the status action a lot. But I think it will be problematic to
just introduce status, and let the requirement that init-scripts fail not
if the package has been removed.
That's why I meant one could easily catch all three here :D


> I think that's the goal of the DEP process:
> 
>     http://dep.debian.net/

>> No... see the example with cryptsetup I've described above, where
>> following the policy would open a security problem.
> I don't agree that your example has proven that.  It looks theoretical
to
> me, and a stretch to call that a security issue in Debian (as opposed to
a
> misunderstanding by the user of what's required to maintain a consistent
> system).  If the user wants to have encrypted devices, they need to not
> remove the packages that handle device encryption.
Well I personally like to compare that with e.g. tools like wipe.
If you say
$ wipe file
you expect the file either to be correctly wiped, or getting an error.
Similar to if you encrypt a file with gpg.


Best wishes,
Chris.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. (Sun, 01 Aug 2010 21:33:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 01 Aug 2010 21:33:03 GMT) Full text and rfc822 format available.

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

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Russ Allbery <rra@debian.org>
Cc: 208010@bugs.debian.org
Subject: Re: Bug#208010: Require init.d scripts comply with LSB
Date: Sun, 01 Aug 2010 23:32:11 +0200
[Message part 1 (text/plain, inline)]
Hey Russ and others :)


I've thought about that issue a little bit again,... and have to further
points which might be worth discussion:


1) Right now, init-scripts, as well as cron-scripts are configuration
files, right?

I guess that made a lot of sense, when initscripts where a) much easier,
b) not very well configurable.

Nowadays we have however quite well configurable scripts via the
configuration files in /etc/default (I guess also cron-scripts would be
allowed to place their config files there, right?).

I (personally) rarely seen that one really needs to modify an
initscript. Usually, if the desired modification are reasonable,
maintainers are willingly to make the respective thing configurable via
and /etc/default file, if one asks them.

The only (main) thing left, which I could see right now, one may want to
modify is the LSB header to control the startup order.


This has in principle nothing directly to do with this bug, and at your
consent, I'd report this as a separate "bug" to make discussion
possible... but...



2) if init-scripts are meant to be config files (I mean even on a
very-long-term-scale) it's intended that people can change them and e.g.
do the following:
Adding a required-start on firewall-scripts to the ssh init-scipt. To
guarantee that this is always started before ssh.

Now if we require init-scripts to exit 0 if the package has been removed
(!purged), there is no change to see, that the requirement is actually
not longer met, is it?


Thanks,
Chris.
[smime.p7s (application/x-pkcs7-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#208010; Package debian-policy. (Fri, 13 Aug 2010 17:51: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, 13 Aug 2010 17:51:03 GMT) Full text and rfc822 format available.

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

From: Russ Allbery <rra@debian.org>
To: Christoph Anton Mitterer <calestyo@scientia.net>
Cc: 208010@bugs.debian.org
Subject: Re: Bug#208010: Require init.d scripts comply with LSB
Date: Fri, 13 Aug 2010 10:48:53 -0700
Christoph Anton Mitterer <calestyo@scientia.net> writes:

> 1) Right now, init-scripts, as well as cron-scripts are configuration
> files, right?

Yes.  Nearly everything in /etc is a configuration file.

> I (personally) rarely seen that one really needs to modify an
> initscript.

I frequently need to modify init scripts, so our experience differs here.

> This has in principle nothing directly to do with this bug, and at your
> consent, I'd report this as a separate "bug" to make discussion
> possible... but...

It would surprise me if there were consensus to make init scripts not
configuration files.  You can certainly propose that change in another
separate bug, but my guess is that it will end up being rejected.

> 2) if init-scripts are meant to be config files (I mean even on a
> very-long-term-scale) it's intended that people can change them and e.g.
> do the following:

> Adding a required-start on firewall-scripts to the ssh init-scipt. To
> guarantee that this is always started before ssh.

> Now if we require init-scripts to exit 0 if the package has been removed
> (!purged), there is no change to see, that the requirement is actually
> not longer met, is it?

If you remove packages from your system that you expect to be running, you
get to keep both pieces.  The purpose of Policy is not to keep system
administrators from taking inconsistent and contradictory actions on their
own systems.

-- 
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#208010; Package debian-policy. (Fri, 13 Aug 2010 18:03:06 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, 13 Aug 2010 18:03:06 GMT) Full text and rfc822 format available.

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

From: Russ Allbery <rra@debian.org>
To: Christoph Anton Mitterer <calestyo@scientia.net>
Cc: 208010@bugs.debian.org
Subject: Re: Bug#208010: Require init.d scripts comply with LSB
Date: Fri, 13 Aug 2010 11:01:23 -0700
Christoph Anton Mitterer <calestyo@scientia.net> writes:

> I recently had a case which made me looking into this and Carsten Hey
> pointed me to that specific bug report here.

> Has there been any progress on this?

> I mean we already use LSB init script headers for dependency based
> booting...

> Many scripts already have the status action (and then follow the exit
> codes as implied by LSB).

> In my opinion it would make sense, to quite closely follow
> http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html in Debian.

It looks like I didn't ever reply to the general question about the status
of this bug, so let me do that.  The following is my opinion about the
current status of this set of related issues.  Other people may have
different takes.  I personally think it would be useful to separate out
the various different things that could change in Debian to support LSB
init scripts and tackle them separately.

LSB init script headers are already widely adopted in the project and need
to be documented in Policy.  This is just waiting for someone to take the
wiki page at http://wiki.debian.org/LSBInitScripts and turn the
documentatino of the LSB header into Policy language and propose it for
inclusion.  I think this is completely uncontroversial and would go in
quickly, so it should be done independent of other LSB issues.

I believe there is general consensus that the status argument to init
scripts would be a good thing to support.  There may be some disagreement
over whether it should go directly into Policy or whether it's more of a
best practice thing.  I would support putting it directly into Policy as a
"should" directive, even though this would make a lot of packages buggy.
That may or may not end up being consensus.  This will also require
modifying the current Policy example of how to make an init script do
nothing when the package is not installed so that it can still return a
negative result to status.

Use of the LSB functions in init scripts and standardization of the output
format is a large and difficult discussion.  I think the first step in
that discussion would be to provide better wrappers around the LSB
functions, since right now using them is much more difficult than it
should be and results in complex and hard-to-read init scripts.  To
properly call those functions now, one has to turn straightforward logic
like:

    echo -n "Starting $DESC: "
    start-stop-daemon -c lbcd -g lbcd --start --quiet \
        --pidfile $PIDDIR$NAME.pid --exec $DAEMON -- $DAEMON_OPTS
    echo "$NAME."

into:

    [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
    start-stop-daemon -c lbcd -g lbcd --start --quiet \
        --pidfile $PIDDIR$NAME.pid --exec $DAEMON -- $DAEMON_OPTS
    case "$?" in
      0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
      2)   [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    esac

and it gets considerably worse if you're trying to manage multiple daemons
from the same init script.  We need some better functions for handling
this if we're going to ask people to use those functions across the board.
Only after some better abstractions are available do I think this is
likely to be able to go forward, and even then I think it should go
through the Developer's Reference first.

I think making developers aware of the LSB status codes is a good idea,
but I don't believe there's any consensus on asking all init scripts in
Debian to change.  I think that writing up a best practice for init script
exit codes following the LSB with the exception of how init scripts are
handled when the package is removed but not purged would be a good first
step.  That writeup would belong, IMO, in the Developer's Reference, not
in Policy, at least to start with.

I'm strongly opposed to changing Debian's requirements about init script
behavior when the package is removed but not purged, apart from the status
command, and I'm fairly sure I'm not the only one.  I doubt that
discussion will go anywhere, but of course you're free to try if you want
to.

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




Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 13:07:47 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.