Debian Bug report logs - #291148
status action for init.d scripts

Toggle useless messages

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

From: Javier Fernández-Sanguino Peña <jfs@computer.org>

To: submit@bugs.debian.org

Subject: [PROPOSAL] Add a 'status' option in init.d scripts

Date: Wed, 19 Jan 2005 01:30:55 +0100

[Message part 1 (text/plain, inline)]

Package: debian-policy
Version: 3.6.1.1
Priority: wishlist
Tags: patch

[ Note: I understand that this status suggestion is covered (without a
valid example in #208010) but I believe that LSB compliance also forces
some other things (like exit codes) which is still under discussion.
That's why I'm opening this up as a different bug report and not
following up there. If this is fixed through applying the patch at
#208010 please consider the example change introduced in the 
patch attached (which actually has a 'status' function that works
although there is obviously room for improvement) ] 

I would like a new option to be added to init.d scripts: 'status' 
which basicly tells what status is the service currently in 
(either running or dead).

This option is quite handy when you want to determine the system status
(instead of blindly trying 'restart' and see what happens). It is
also useful also to determine if the start-stop-daemon call
succeeded and left a running program. Currently most init.d scripts
will happily start up services which are not correctly configured
and admins will not notice that they didn't start up until they
check the service itself (is it running? what do the logs say?).

I would appreciate more consistent behaviour here, one thing I like of
other distributions is that you actually get to see if the system
starts up succesfully just by looking at the boot sequence. In Debian,
many init.d scripts just don't check wether they left a running
service. This 'status' option proposal is a first step towards enforcing
init.d scripts to do so.

I've attached a patch with the proposal including both the 
description and a change to the sample init.d script implementing it.
Please consider this for Debian's policy.

Regards

Javier

[policy.status.diff (text/plain, attachment)]

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

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

From: Stephen Gildea <gildea@stop.mail-abuse.org>

To: 291148@bugs.debian.org

Subject: 'status' option should be required of init.d scripts

Date: Tue, 31 May 2005 08:38:01 -0700

If bug #208010 goes too far, this bug report doesn't go far enough.
The "status" option should be required, not optional.  Only if it can be
counted on will it be useful.

I'm interested in being able to check the status of services when I
suspend and resume a laptop.  Some services must be stopped before a
suspend can happen; others must be restarted after a resume.  But in all
cases the restart-on-resume should happen only if the service was
running before the suspend.

The "hibernate" package provides nice wrappers for suspend and resume,
including the ability to stop and restart services.  But it can't
reliably restart exactly the services that were running, because it
cannot check which services were running.

The set of services actually running may not be the list that was
started automatically when the current run level was entered.  Packages
such as "whereami" may stop or start services based on the current
network environment of a portable computer.  Or the user may have
stopped or started a service manually.  So the only way to know whether
a service is running is to ask it, via a "status" option.

 < Stephen

Message #15 received at 291148@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <allomber@math.u-bordeaux.fr>

To: Stephen Gildea <gildea@stop.mail-abuse.org>, 291148@bugs.debian.org

Subject: Re: Bug#291148: 'status' option should be required of init.d scripts

Date: Tue, 31 May 2005 21:15:22 +0200

On Tue, May 31, 2005 at 08:38:01AM -0700, Stephen Gildea wrote:
> If bug #208010 goes too far, this bug report doesn't go far enough.
> The "status" option should be required, not optional.  Only if it can be
> counted on will it be useful.

Some initscripts cannot provide a status, because they do not launch
daemons.

> I'm interested in being able to check the status of services when I
> suspend and resume a laptop.  Some services must be stopped before a
> suspend can happen; others must be restarted after a resume.  But in all
> cases the restart-on-resume should happen only if the service was
> running before the suspend.
> 
> The "hibernate" package provides nice wrappers for suspend and resume,
> including the ability to stop and restart services.  But it can't
> reliably restart exactly the services that were running, because it
> cannot check which services were running.
> 
> The set of services actually running may not be the list that was
> started automatically when the current run level was entered.  Packages
> such as "whereami" may stop or start services based on the current
> network environment of a portable computer.  Or the user may have
> stopped or started a service manually.  So the only way to know whether
> a service is running is to ask it, via a "status" option.

Why not start by providing patches to init scripts ?
Debian initscripts sorely need a cleansing.

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

Imagine a large red swirl here. 

Message #20 received at 291148@bugs.debian.org (full text, mbox, reply):

From: Manoj Srivastava <srivasta@debian.org (va, manoj)>

To: 291148@bugs.debian.org

Subject: Re: Bug#291148: 'status' option should be required of init.d scripts

Date: Mon, 20 Jun 2005 19:49:10 -0500

[Message part 1 (text/plain, inline)]

Hi,

        This seems like a reasonable suggestion, especially if it is
 compatible with LSB strictures. Are there any objections to allowing
 policy to mention an optional status command for initscripts?

        I am seconding this proposal. Any others?

        manoj
-- 
perfect guest: One who makes his host feel at home.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

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

Message #25 received at 291148@bugs.debian.org (full text, mbox, reply):

From: <allomber@math.u-bordeaux.fr>

To: Javier Fernández-Sanguino Peña <jfs@computer.org>

Cc: 291148@bugs.debian.org

Subject: Re: [PROPOSAL] Add a 'status' option in init.d scripts

Date: Tue, 21 Jun 2005 21:57:35 +0200

On Wed, Jan 19, 2005 at 01:30:55AM +0100, Javier Fernández-Sanguino Peña wrote:
> --- policy.sgml.orig	2005-01-19 01:10:37.000000000 +0100
> +++ policy.sgml	2005-01-19 01:13:05.000000000 +0100
> @@ -5392,13 +5392,17 @@
>  	      <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><p>show the status of the service (either running
> +                  or dead).</item>
>  	    </taglist>

I don't think this is a sufficient specification. We should make it
clear what status should display in the different case:

1) init script does not start a daemon
2.a) init script start a daemon  which is running
2.b) init script start a daemon  which is not running
3) init script start several daemons 
4) init script was disabled in config

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

Imagine a large red swirl here. 

Message #30 received at 291148@bugs.debian.org (full text, mbox, reply):

From: Manoj Srivastava <srivasta@debian.org (va, manoj)>

To: <allomber@math.u-bordeaux.fr>

Cc: 291148@bugs.debian.org

Subject: Re: Bug#291148: [PROPOSAL] Add a 'status' option in init.d scripts

Date: Tue, 21 Jun 2005 16:10:53 -0500

On Tue, 21 Jun 2005 21:57:35 +0200,   <allomber@math.u-bordeaux.fr> said: 

> On Wed, Jan 19, 2005 at 01:30:55AM +0100, Javier Fernández-Sanguino Peña wrote:
>> --- policy.sgml.orig 2005-01-19 01:10:37.000000000 +0100
>> +++ policy.sgml 2005-01-19 01:13:05.000000000 +0100
>> @@ -5392,13 +5392,17 @@ <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><p>show the status of the service (either running
>> + or dead).</item>
>> </taglist>

> I don't think this is a sufficient specification.

        Umm, why? Why can't we leave it to the maintainer to determine
 the current status of the service?

> We should make it clear what status should display in the different
> case:

> 1) init script does not start a daemon
> 2.a) init script start a daemon which is running 2.b) init script
> start a daemon which is not running
> 3) init script start several daemons
> 4) init script was disabled in config

        I think rather than trying to decree a policy, and over
 engineer an optional action for an init script meant mostly for user
 consumption, we should let the developers come up with whatever works
 best for them. Heck, even the LSB says nothing more about  the status
 action (apart from specifying some exit codes).

        At this point, there are no existing standards or practices
 for it to warrant a more explicit  policy; once we figure out, in
 practice, what would work best, we can _then_ try making policy,
 IMHO.

        manoj

-- 
"We don't have to protect the environment -- the Second Coming is at
hand." James Watt
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Message #35 received at 291148@bugs.debian.org (full text, mbox, reply):

From: Javier Fernández-Sanguino Peña <jfs@computer.org>

To: allomber@math.u-bordeaux.fr

Cc: 291148@bugs.debian.org

Subject: Re: [PROPOSAL] Add a 'status' option in init.d scripts

Date: Wed, 22 Jun 2005 21:41:01 +0200

On Tue, Jun 21, 2005 at 09:57:35PM +0200, allomber@math.u-bordeaux.fr wrote:
> 
> I don't think this is a sufficient specification. We should make it
> clear what status should display in the different case:

Hmm.. When I'm asking for a status, I'm asking for a status of a given 
daemon, not a status of what the init script does. How about the 
following:

for each daemon that the init.d might start; 
do
1- daemon is running
1.a- but has not been started up by init.d script
1.b- and was started by the init.d  script
2- daemon is not running
2.a- and the init.d script will not start it
2.a.a- since configuration is missing
2.a.b- since it is configured not to
2.b- but was started by init and FAILED
2.c- since it was stopped by init
done

User messages (and exit status) could be tailored down to provide that
info:

1.a-   Checking XXX daemon: running.
1.b-   Checking XXX daemon: running (not started by init.d)
2.a.a- Checking XXX daemon: stopped (daemon not configured)
2.a.b- Checking XXX daemon: stopped (init.d disabled)
2.b -  Checking XXX daemon: stopped (FAILED)
2.c -  Checking XXX daemon: stopped

How does it sound like?


Javier

Message #40 received at 291148@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <allomber@math.u-bordeaux.fr>

To: Manoj Srivastava <srivasta@debian.org>

Cc: 291148@bugs.debian.org

Subject: Re: Bug#291148: [PROPOSAL] Add a 'status' option in init.d scripts

Date: Fri, 24 Jun 2005 18:24:56 +0200

On Tue, Jun 21, 2005 at 04:10:53PM -0500, Manoj Srivastava wrote:
> On Tue, 21 Jun 2005 21:57:35 +0200,   <allomber@math.u-bordeaux.fr> said: 
> 
> > On Wed, Jan 19, 2005 at 01:30:55AM +0100, Javier Fernández-Sanguino Peña wrote:
> >> --- policy.sgml.orig 2005-01-19 01:10:37.000000000 +0100
> >> +++ policy.sgml 2005-01-19 01:13:05.000000000 +0100
> >> @@ -5392,13 +5392,17 @@ <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><p>show the status of the service (either running
> >> + or dead).</item>
> >> </taglist>
> 
> > I don't think this is a sufficient specification.
> 
>         Umm, why? Why can't we leave it to the maintainer to determine
>  the current status of the service?

That is not the question. The question is how to return it to the user.

> > We should make it clear what status should display in the different
> > case:
> 
> > 1) init script does not start a daemon
> > 2.a) init script start a daemon which is running 2.b) init script
> > start a daemon which is not running
> > 3) init script start several daemons
> > 4) init script was disabled in config
> 
>         I think rather than trying to decree a policy, and over
>  engineer an optional action for an init script meant mostly for user
>  consumption, we should let the developers come up with whatever works
>  best for them. Heck, even the LSB says nothing more about  the status
>  action (apart from specifying some exit codes).

Then the proposal is quite useless. Policy already allow initscript to
implement a status option. The only point of mention it in policy is to
get some amount of consistency among those that implement it.

>         At this point, there are no existing standards or practices
>  for it to warrant a more explicit  policy; once we figure out, in
>  practice, what would work best, we can _then_ try making policy,
>  IMHO.

At keast the LSB document it, see LSB 20.2:

status	print the current status of the service

If the status action is requested, the init script will return the
following exit status codes.

0	program is running or service is OK
1	program is dead and /var/run pid file exists
2	program is dead and /var/lock lock file exists
3	program is not running
4	program or service status is unknown
5-99	reserved for future LSB use
100-149	reserved for distribution use
150-199	reserved for application use
200-254	reserved

What is exactly printed is distro-specific, but as far as Debian is 
concerned, we should propose something consistent with what is printed
by the other options(start stop, etc).

I would note that the LSB text say 'program' here whereas it said
'service' previously. This is inconsistent given that the service might
not be implemented by a program.

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

Imagine a large red swirl here. 

Message #45 received at 291148@bugs.debian.org (full text, mbox, reply):

From: Manoj Srivastava <srivasta@debian.org (va, manoj)>

To: debian-policy@lists.debian.org

Cc: 291148@bugs.debian.org

Subject: Re: Bug#291148: [PROPOSAL] Add a 'status' option in init.d scripts

Date: Fri, 24 Jun 2005 12:33:45 -0500

On Fri, 24 Jun 2005 18:24:56 +0200, Bill Allombert
<allomber@math.u-bordeaux.fr> said:  

>> I think rather than trying to decree a policy, and over engineer an
>> optional action for an init script meant mostly for user
>> consumption, we should let the developers come up with whatever
>> works best for them. Heck, even the LSB says nothing more about the
>> status action (apart from specifying some exit codes).

> Then the proposal is quite useless. Policy already allow initscript
> to implement a status option. The only point of mention it in policy
> is to get some amount of consistency among those that implement it.

>> At this point, there are no existing standards or practices for it
>> to warrant a more explicit policy; once we figure out, in practice,
>> what would work best, we can _then_ try making policy, IMHO.

> At keast the LSB document it, see LSB 20.2:

> status print the current status of the service

> If the status action is requested, the init script will return the
> following exit status codes. {SNIP]

> What is exactly printed is distro-specific, but as far as Debian is
> concerned, we should propose something consistent with what is
> printed by the other options(start stop, etc).

        Then I suggest you come up with a draft, see how it could be
 implemented by a bunch of scripts in /etc/init.d,  incorporate the
 feedback that shall result, and go at it again; when the design of
 the status action has stabilized, and field tested, _then_ we come
 back and implement this in policy.

        Perhaps you should start out with coming up with a
 recommendation in developers reference, and see how well that initial
 recommendation plays out?  I think it would be a good idea to put the
 final, poliched status action specification into policy, but I think
 doing initial design by policy is not such a great idea.


        manoj
-- 
The existence of god implies a violation of causality.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Message #50 received at 291148@bugs.debian.org (full text, mbox, reply):

From: Matt Zimmerman <mdz@debian.org>

To: 291148@bugs.debian.org

Subject: Re: Bug#291148: [PROPOSAL] Add a 'status' option in init.d scripts

Date: Fri, 24 Jun 2005 21:21:57 -0700

I agree with Manoj's suggestion.  The best way to go about it would be to
draft a complete proposal (including standardizing the output format), start
patching packages in unstable, and go from there.

FWIW, I think it would be appropriate to add an option to start-stop-daemon
to support this use case.  It already has most of the necessary code, and it
would fit well with its existing interface.

-- 
 - mdz

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

From: Dustin Kirkland <kirkland@canonical.com>

To: 291148@bugs.debian.org

Cc: Matt Zimmerman <mdz@canonical.com>

Subject: Re: Bug#291148: [PROPOSAL] Add a 'status' option in init.d scripts

Date: Fri, 13 Jun 2008 14:00:19 -0500

[Message part 1 (text/plain, inline)]

On Fri, 24 Jun 2005 21:21:57 -0700, Matt Zimmerman <mdz@debian.org>
wrote:
> I agree with Manoj's suggestion.  The best way to go about it would be to
> draft a complete proposal (including standardizing the output format), start
> patching packages in unstable, and go from there.

Please see the latest patch against lsb-base and comments at:
 * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483285

That patch defines a status_of_proc() function.  The output format
conforms with the exit codes and log_[success|failure]_msg() functions
as defined in the LSB Reference Specification:
 * http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

> FWIW, I think it would be appropriate to add an option to start-stop-daemon
> to support this use case.  It already has most of the necessary code, and it
> would fit well with its existing interface.

Obviously, getting the library status_of_proc() function (or similar)
into /lib/lsb/init-functions would be the logical first step.

Once that occurs, then patching start-stop-daemon should be simple.

Additionally, various daemons' init scripts would also need a status)
section that would either call status_of_proc or perhaps
start-stop-daemon --status.


Cheers,
-- 
:-Dustin

Dustin Kirkland
Ubuntu Server Developer
Canonical, LTD
kirkland@canonical.com
GPG: 1024D/83A61194

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

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

From: Peter Eisentraut <petere@debian.org>

To: 291148@bugs.debian.org

Subject: current status

Date: Tue, 28 Feb 2012 14:49:30 +0200

I would like to see whether we can create some progress around this bug.

Over the past few years I've been bugging packages to add the "status"
action to their init scripts.  We currently have about 55% of packages
supporting this, including most of the most popular packages.  We also
have a lintian tag that informs about missing support.  The
status_of_proc function in /lib/lsb/init-functions now provides a de
factor reference implementation of the status action.

I have written this up in more detail in the wiki:
http://wiki.debian.org/LSBInitScripts/StatusSupport

So at this point, is there anything more that needs to be done other
than writing some language suitable for inclusion into the policy?

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

From: Peter Eisentraut <petere@debian.org>

To: 291148@bugs.debian.org

Subject: Proposal

Date: Sat, 12 May 2012 23:10:50 +0300

[Message part 1 (text/plain, inline)]

So since no one had anything to add, here is a concrete proposal.  All
of this reflects current practice, I believe.  Since the addition of
status_of_proc to /lib/lsb/init-functions, this has been quite
standardized in practice, and as I wrote earlier, more than half of the
affected packages are already doing this.

      * Add "status" as an optional init script option (similar to
        "reload").  No one objected to that.
      * Require exit status 0 or not 0.  There were concerns about
        anything more specific, and it's not necessary in practice, as
        consumers of this generally only check for 0 or not 0.  Could be
        refined in the future.
      * Add footnote encouraging use of LSB exit statuses anyway.
      * Add footnote about what "service is running" might mean.  Some
        people in the discussion were concerned about this being
        ambiguous, some were concerned about making it too specific.
        The main nonhuman consumers of this interface are system
        monitoring programs that will decide to run "start" if "status"
        reports not running.  So it is reasonable to define the behavior
        of "status" in terms of "start".
      * Add something simple about console messages from status option.
        That whole section seems to have been overtaken by reality, but
        what I wrote is pretty close to it.

I think this matter could be moved from Discussion to Proposal now.

[policy-initd-status.patch (text/x-patch, attachment)]

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

From: Guillem Jover <guillem@debian.org>

To: Peter Eisentraut <petere@debian.org>, 291148@bugs.debian.org

Subject: Re: Bug#291148: Proposal

Date: Sun, 13 May 2012 02:23:05 +0200

On Sat, 2012-05-12 at 23:10:50 +0300, Peter Eisentraut wrote:
> So since no one had anything to add, here is a concrete proposal.  All
> of this reflects current practice, I believe.  Since the addition of
> status_of_proc to /lib/lsb/init-functions, this has been quite
> standardized in practice, and as I wrote earlier, more than half of the
> affected packages are already doing this.
> 
>       * Add "status" as an optional init script option (similar to
>         "reload").  No one objected to that.
>       * Require exit status 0 or not 0.  There were concerns about
>         anything more specific, and it's not necessary in practice, as
>         consumers of this generally only check for 0 or not 0.  Could be
>         refined in the future.
>       * Add footnote encouraging use of LSB exit statuses anyway.
>       * Add footnote about what "service is running" might mean.  Some
>         people in the discussion were concerned about this being
>         ambiguous, some were concerned about making it too specific.
>         The main nonhuman consumers of this interface are system
>         monitoring programs that will decide to run "start" if "status"
>         reports not running.  So it is reasonable to define the behavior
>         of "status" in terms of "start".
>       * Add something simple about console messages from status option.
>         That whole section seems to have been overtaken by reality, but
>         what I wrote is pretty close to it.

Just a quite note, start-stop-daemon got a --status command with LSB
semantics in dpkg 1.16.1.

thanks,
guillem

Message #79 received at 291148-done@bugs.debian.org (full text, mbox, reply):

From: Sean Whitton <spwhitton@spwhitton.name>

To: 291148-done@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: Bug#291148: 'status' option should be required of init.d scripts

Date: Thu, 3 Aug 2017 15:48:59 -0400

[Message part 1 (text/plain, inline)]

user debian-policy@packages.debian.org
usertag -1 = normative dubious
tag -1 +wontfix
thanks

On Tue, May 31, 2005 at 08:38:01AM -0700, Stephen Gildea wrote:
> The "status" option should be required, not optional.  Only if it can be
> counted on will it be useful.

init scripts now follow LSB, which mandates the status option.

-- 
Sean Whitton

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

Send a report that this bug log contains spam.