"status" function for init scripts

[Dustin Kirkland ]

Binary package hint: lsb

Ubuntu Hardy, lsb-base 3.1-24ubuntu2

This bug has been discussed on the Ubuntu-devel mailing list [1].

Only a very few of the service init scripts in /etc/init.d, (apparmor, cupsys, mysql, postfix, postgresql) have implemented the "status" action.

The Linux Standard Base init script specification [2] describes the status action in detail, and requires it for LSB compliance. It provides a centralized and direct way of determine if a given service is running or not, with a more sophistication than grepping a process listing. It logs a message to standard out, and exits with one of a number of meaningful codes, also defined in [2].

Users and system administrators with experience in LSB-compliant distributions can be frustrated by a lack of a standard way to determine if a given service is running or not in Ubuntu. Given the LTS designation of Hardy and our interest in furthering the Ubuntu Server, we'd like to add this functionality to several of the init scripts for core daemons that ship on the Ubuntu Server ISO. It will also facilitate the integration with ebox and other status gathering and reporting tools.

We suggest solving this by adding a function to /lib/lsb/init-functions, which is already sourced by most scripts in /etc/init.d. The heavy lifting is performed by the pidofproc() function, which is already defined in that same file. (A proper debdiff will follow.)

+status_of_proc () {
+ local daemon name status
+ daemon="$1"
+ name="$2"
+ pidofproc $daemon >/dev/null
+ status=$?
+ if [ $status -eq 0 ]; then
+ log_success_msg "$name is running."
+ else
+ log_failure_msg "$name is not running."
+ fi
+ return $status
+}

This addition would be followed by patches to init scripts essentially adding a case handler:

+ status)
+ status_of_proc "$DAEMON" "$NAME"
+ exit $?
+ ;;

The risk should be minimal. It will clearly not affect the functionality of starting and stopping daemons, and thus a minimal chance of regression. We will push the changes to Debian, as there is a similar bug in Debian's bug tracker [3].

[1] https://lists.ubuntu.com/archives/ubuntu-devel/2008-March/025176.html
[2] http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291148

[Stephen Gildea (gildea)]

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

[Bill Allombert (allomber)]

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. <email address hidden>

Imagine a large red swirl here.

[Manoj (srivasta)]

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 <email address hidden> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

[Bill Allombert (allomber)]

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. <email address hidden>

Imagine a large red swirl here.

[Manoj (srivasta)]

On Tue, 21 Jun 2005 21:57:35 +0200, <email address hidden> 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 <email address hidden> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

[Javier Fernández-Sanguino (jfs)]

On Tue, Jun 21, 2005 at 09:57:35PM +0200, <email address hidden> 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

[Bill Allombert (allomber)]

On Tue, Jun 21, 2005 at 04:10:53PM -0500, Manoj Srivastava wrote:
> On Tue, 21 Jun 2005 21:57:35 +0200, <email address hidden> 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. <email address hidden>

Imagine a large red swirl here.

[Manoj (srivasta)]

On Fri, 24 Jun 2005 18:24:56 +0200, Bill Allombert
<email address hidden> 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 <email address hidden> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

[Matt Zimmerman (mdz)]

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

[Manoj (srivasta)]

severity 267142 wishlist
retitle 267142 [DISCUSS] Sections 10.4 and 6.1 are inconsistent
severity 314808 wishlist
retitle 314808 [DISCUSS] Incorrect directory for web applications.
severity 331532 wishlist
retitle 331532[DISCUSS] change §10.4 "set -e OR check return status" to AND or be rewritten
tags 99933 -patch
tags 122817 -patch
tags 143941 -patch
tags 164474 -patch
tags 181123 -patch
tags 208010 -patch
tags 208011 -patch
tags 291148 -patch
tags 299007 -patch
tags 348336 -patch
--
"It's like deja vu all over again." -- Yogi Berra
Manoj Srivastava <email address hidden> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

[Russ Allbery (rra-debian)]

# Setting up user categories for Policy bug triage and to help in the
# process. This uses the same classification scheme as mine adjusted by
# Manoj and previously discussed on the mailing list, with a few
# modifications so that the existing bug system tags can be used where
# possible:
#
# * Use patch for the wording tag so that a traditional view shows those.
# * Use pending for accepted, since they mean the same thing.
# * Use wontfix for rejected, likewise.
# * Sort by severity before issue-status instead of afterwards.
# * Don't sort by classification; issue-status supersedes it.
#
# We still sort by status first, which means that accepted and rejected
# bugs fall out of the main section into the bottom section.

user <email address hidden>
usercategory issue-type [hidden]
 * Issue Type [tag=]
  + Normative [normative]
  + Informative [informative]
  + Packaging [packaging]
  + Unclassified []

usercategory issue-status [hidden]
 * Issue Status [tag=]
  + Issue Raised [issue]
  + Under Discussion [discussion]
  + Opinion Solicited [opinion]
  + Change Proposed [proposal]
  + Wording Proposed [patch]
  + Wording Seconded [seconded]
  + Wording Accepted [pending]
  + Rejected [wontfix]
  + Unknown []

usercategory normal
 * status
 * issue-type
 * severity
 * issue-status

usercategory old
 * status
 * severity
 * classification

package debian-policy

usertag 452393 informative issue
retitle 452393 Clarify difference between required and important priorities
tag 452393 -patch

usertag 163666 informative discussion
retitle 163666 Interpretation of [arch] is unclear with alternatives (|)
usertag 186102 informative discussion
retitle 186102 Suggest better date-based version numbers

usertag 175202 informative proposal
retitle 175202 Clarify Perl package naming convention with more examples
usertag 218897 informative proposal
retitle 218897 Explicitly say dpkg-divert --local is a bad idea in packages
usertag 328951 informative proposal
retitle 328951 Clarify relationship between targets and Build-Depends{,-Indep}
severity 328951 wishlist
usertag 442134 informative proposal
retitle 442134 Inconsistency: half-configured vs. failed-config

usertag 455602 informative
usertag 422552 informative

usertag 89038 normative issue
retitle 89038 [mime-policy] Include update-mime behavior
usertag 181123 normative issue
retitle 181123 Regulate init script behavior in unusual cases
usertag 120418 normative issue
retitle 120418 Policy for code using CPU extensions
usertag 122038 normative issue
retitle 122038 Use of /var/backups is apparently undocumented
usertag 161912 normative issue
retitle 161912 Drop 30000-59999 uid/gid reservation
usertag 186700 normative issue
retitle 186700 Sorting and meaning of an empty Debian revision is unclear
severity 186700 minor
usertag 192571 normative issue
retitle 192571 Size limit for doc packages
usertag 215549 normative issue
retitle 215549 reconfigure argument to postinst
usertag 263448 normative issue
retitle 263448 Separate font directory for non-free fonts
usertag 276160 normative issue
usertag 400322 normative issue
retitle 400322 Specify which dependency fields may be restricted by arch
usertag 40...

[Dustin Kirkland  (kirkland)]

Binary package hint: lsb

Ubuntu Hardy, lsb-base 3.1-24ubuntu2

This bug has been discussed on the Ubuntu-devel mailing list [1].

Only a very few of the service init scripts in /etc/init.d, (apparmor, cupsys, mysql, postfix, postgresql) have implemented the "status" action.

The Linux Standard Base init script specification [2] describes the status action in detail, and requires it for LSB compliance. It provides a centralized and direct way of determine if a given service is running or not, with a more sophistication than grepping a process listing. It logs a message to standard out, and exits with one of a number of meaningful codes, also defined in [2].

Users and system administrators with experience in LSB-compliant distributions can be frustrated by a lack of a standard way to determine if a given service is running or not in Ubuntu. Given the LTS designation of Hardy and our interest in furthering the Ubuntu Server, we'd like to add this functionality to several of the init scripts for core daemons that ship on the Ubuntu Server ISO. It will also facilitate the integration with ebox and other status gathering and reporting tools.

We suggest solving this by adding a function to /lib/lsb/init-functions, which is already sourced by most scripts in /etc/init.d. The heavy lifting is performed by the pidofproc() function, which is already defined in that same file. (A proper debdiff will follow.)

+status_of_proc () {
+ local daemon name status
+ daemon="$1"
+ name="$2"
+ pidofproc $daemon >/dev/null
+ status=$?
+ if [ $status -eq 0 ]; then
+ log_success_msg "$name is running."
+ else
+ log_failure_msg "$name is not running."
+ fi
+ return $status
+}

This addition would be followed by patches to init scripts essentially adding a case handler:

+ status)
+ status_of_proc "$DAEMON" "$NAME"
+ exit $?
+ ;;

The risk should be minimal. It will clearly not affect the functionality of starting and stopping daemons, and thus a minimal chance of regression. We will push the changes to Debian, as there is a similar bug in Debian's bug tracker [3].

[1] https://lists.ubuntu.com/archives/ubuntu-devel/2008-March/025176.html
[2] http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291148

[Scott James Remnant (Canonical) (canonical-scott)]

Thanks Mathias,

udev should not have a "status" function since it will incline people to believe that running "/etc/init.d/udev stop" or "/etc/init.d/udev start" will do something useful when infact they can seriously break a system.

[Steve Langasek (vorlon)]

These patches all seem to be missing a versioned dependency on the version of lsb-base that will provide this new status_of_proc function.

They also don't take into account that several of these init scripts use "set -e", which makes "exit $?" a completely redundant no-op...

[LaMont Jones (lamont)]

And, as noted in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291148 , this really needs a complete specification, and should probably be supported via some new code in start-stop-daemon.

[Dustin Kirkland  (kirkland)]

Patch submitted to Debian, marking In Progress, and I'm taking ownership.

:-Dustin

[Nicolas Valcarcel (nvalcarcel)]

I think we need to wait until lsb is patched and uploaded to start changing the rest of the packages, also we will need to depend on the specific version of lsb (as pointed by steve on his comment).

Also the patch of apache doesn't seem to use the standard procedure described by Dustin.

Onno: Please update your patches whenever the lsb-base package is uploaded into the ubuntu repositories including the patch suggested by Dustin. Thanks for your work!

[Dustin Kirkland  (kirkland)]

On Mon, Jun 2, 2008 at 2:36 PM, Nicolas Valcárcel (nxvl)
<email address hidden> wrote:
> Onno: Please update your patches whenever the lsb-base package is
> uploaded into the ubuntu repositories including the patch suggested by
> Dustin. Thanks for your work!

Nicolas-

We're really hoping Debian will pick up the patches to lsb-base. Or,
at the very least, get some feedback from Debian and find out what
more we need to do to get them acceptable.

As soon as that happens, we will sync Debian's lsb-base to Ubuntu, and
start patching other packages. Obviously, upstream in Debian wherever
possible.

Thanks,
:-Dustin

[Nicolas Valcarcel (nvalcarcel)]

Yes, that's what i meant, but as i see on the debian-policy bug on BTS some
DD's want to check the packages using it before including that on the DP,
but that's only a policy issue, not a real technical one, i also hope that
Debian include the lsb-base patch, but if not we can include it on the
ubuntu package and start working from there and try to make debian include
it later. But now we have some time to do this, so let's wait

On Mon, Jun 2, 2008 at 5:44 PM, Dustin Kirkland <email address hidden>
wrote:

> On Mon, Jun 2, 2008 at 2:36 PM, Nicolas Valcárcel (nxvl)
> <email address hidden> wrote:
> > Onno: Please update your patches whenever the lsb-base package is
> > uploaded into the ubuntu repositories including the patch suggested by
> > Dustin. Thanks for your work!
>
> Nicolas-
>
> We're really hoping Debian will pick up the patches to lsb-base. Or,
> at the very least, get some feedback from Debian and find out what
> more we need to do to get them acceptable.
>
> As soon as that happens, we will sync Debian's lsb-base to Ubuntu, and
> start patching other packages. Obviously, upstream in Debian wherever
> possible.
>
> Thanks,
> :-Dustin
>
> --
> "status" function for init scripts
> https://bugs.launchpad.net/bugs/203169
> You received this bug notification because you are a member of Ubuntu
> Server Team, which is a direct subscriber.
>
> --
> Ubuntu-server-bugs mailing list
> <email address hidden>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
>

[Launchpad Janitor (janitor)]

This bug was fixed in the package lsb - 3.2-12ubuntu1

---------------
lsb (3.2-12ubuntu1) intrepid; urgency=low

  * Merge from debian unstable, remaining changes:
    - init-functions:
      + Debian has a "return 0" that should be "return 3" per LSB spec
      + Make pidof call "set -e safe", LP: #204594
      + Add status_of_proc() function, LP: #203169
    - debian/control:
      + Remove python from conflicts
      + Keep Ubuntu's Depends and Suggests

 -- Dustin Kirkland <email address hidden> Wed, 04 Jun 2008 13:18:56 -0500

[Dustin Kirkland  (kirkland)]

On Fri, 24 Jun 2005 21:21:57 -0700, Matt Zimmerman <email address hidden>
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
<email address hidden>
GPG: 1024D/83A61194

[Chuck Short (zulcss)]

This should really be fixed now.

chuck

[Dustin Kirkland  (kirkland)]

Patch attached for cron. Please review and apply.

:-Dustin

[Dustin Kirkland  (kirkland)]

All patches attached to this bug are dependent on committing the fix attached to LSB in Bug #246735.
 * https://bugs.edge.launchpad.net/ubuntu/+source/lsb/+bug/246735

:-Dustin

[Dustin Kirkland  (kirkland)]

With Bug #246735, fixed, I'm attaching a set of patches that adds a status action, and a dependency on lsb-base (>= 3.2-12ubuntu2) for:
 * at
 * bind9
 * cron
 * dovecot
 * openssh
 * samba
 * sysklogd

:-Dustin

[Dustin Kirkland  (kirkland)]

Patch for "at"

:-Dustin

[Dustin Kirkland  (kirkland)]

Patch for "bind9"

:-Dustin

[Dustin Kirkland  (kirkland)]

Patch for "cron"

:-Dustin

[Dustin Kirkland  (kirkland)]

Patch for "openssh-server"

:-Dustin

[Dustin Kirkland  (kirkland)]

Patch for "samba"

:-Dustin

[Dustin Kirkland  (kirkland)]

Patch for "sysklogd"

:-Dustin

[Dustin Kirkland  (kirkland)]

Updated patch for bind9, per IRC with lamont.

Changelog:
  * debian/control: Do NOT add dependency on lsb >= 3.2-12ubuntu2, which has the
    status_of_proc() function, per LaMont, to keep from forking Debian's bind9
    package; users without status_of_proc() will get a 127 exit code.
  * debian/bind9.init: Add the 'status' action (LP: #203169).

 -- Dustin Kirkland <email address hidden> Tue, 08 Jul 2008 19:01:04 -0500

[Dustin Kirkland  (kirkland)]

Updated patch for "samba". Remove some quotes which grossly offended lamont. Also, removed the unnecessary for loop.

:-Dustin

[Launchpad Janitor (janitor)]

This bug was fixed in the package bind9 - 1:9.5.0.dfsg.P1-2~build1

---------------
bind9 (1:9.5.0.dfsg.P1-2~build1) intrepid; urgency=low

  * package for intrepid

bind9 (1:9.5.0.dfsg.P1-2) unstable; urgency=low

  * Revert "meta: merge the mess of single-lib packages back into one large
    one." - That way lies madness and pain.
  * init.d/bind9: implement status function. LP: #203169

bind9 (1:9.5.0.dfsg.P1-1) unstable; urgency=low

  * Repackage 9.5.0.dfsg-5 with the -P1 tarball.

bind9 (1:9.5.0.dfsg-5) unstable; urgency=low

  [Internet Software Consortium, Inc]

  * Randomize UDP query source ports to improve forgery resilience.
    (CVE-2008-1447)

  [LaMont Jones]

  * add build-depends: texlive-latex-base, xsltproc, remove Bv9ARM.pdf in clean
  * fix sonames
  * drop unneeded build-deps, since we do not actually deliver B9vARM.pdf
  * meta: cleanup libbind9-41 Provides/Conflicts
  * build: fix sonames for new libraries
  * postinst: really restart bind/lwresd in postinst

 -- LaMont Jones <email address hidden> Tue, 08 Jul 2008 22:00:54 -0600

[Dustin Kirkland  (kirkland)]

Updated samba patch. The last had a transposed character. s/nmdb/nmbd/g

:-Dustin

[Dustin Kirkland  (kirkland)]

As pointed out by LaMont Jones, this bug has grown unwieldy. I'm breaking it out into a separate bug for each package/patch:
 * at: Bug #247091
 * bind9: Bug #247084
 * cron: Bug #201504
 * dovecot: Bug #247096
 * openssh: Bug #247103
 * samba: Bug #247087
 * syslogkd: Bug #247106

:-Dustin

[Daniel Holbach (dholbach)]

Unsubscribing ubuntu-main-sponsors from this bug then.

[Colin Watson (cjwatson)]

openssh fixed via separate bug 247103.

[Florian Hackenberger (f-hackenberger)]

I filed a bug for postgresql:
Bug #248939

[Florian Hackenberger (f-hackenberger)]

And a bug for asterisk:
Bug #248947

[Martin Pitt (pitti)]

Closing postgresql-8.3 task, now handled in bug 248939.

[Thierry Carrez (ttx)]

Closing asterisk task, now handled in bug 248947.

[Dennis P. (dennis-p.)]

I hope this patch is ok.

Dennis

[Onno Benschop (onno-itmaze)]

Dennis, is there any reason your patch doesn't use status_of_proc like all our other patches?

+ status)
+ status_of_proc $DAEMON winbind && exit 0 || exit $?
+

[Dennis P. (dennis-p.)]

Hi Onno,

I don't use "exit 0 || exit $?" because I would like to check all Daemons, and if the ybserv maybe don't run the script will exit without checking the other daemons like ypbind

[Onno Benschop (onno-itmaze)]

On 04/12/08 08:03, Dennis Pattmann wrote:
> Hi Onno,
>
> I don't use "exit 0 || exit $?" because I would like to check all
> Daemons, and if the ybserv maybe don't run the script will exit without
> checking the other daemons like ypbind
>
>
You do realise that most scripts are running under a set -e environment
and will terminate when the exit status is not 0, so, checking other
daemons will not actually happen in the way you think it will.

--
Onno Benschop

Connected via Optus B3 at S31°54'06" - E115°50'39" (Yokine, WA)
--
()/)/)() ..ASCII for Onno..
|>>? ..EBCDIC for Onno..
--- -. -. --- ..Morse for Onno..

ITmaze - ABN: 56 178 057 063 - ph: 04 1219 8888 - <email address hidden>

[Dennis P. (dennis-p.)]

Yes, i have realize that most scripts are running under a set -e environment, but the nis script don't do that. But if you want i can update the patch.

[Onno Benschop (onno-itmaze)]

I'm not going to tell you what to do, but it seems to me that coding
defensively would be smart.

[Dennis P. (dennis-p.)]

Update nis patch.

[Steve Langasek (vorlon)]

The nis package in Ubuntu has been converted to use upstart jobs instead of init scripts, so this no longer applies.