initctl: lacks proper exit codes

Bug #552786 reported by Andrew Pollock
90
This bug affects 16 people
Affects Status Importance Assigned to Milestone
upstart
Triaged
Medium
Unassigned
upstart (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

Binary package hint: upstart

Puppet currently lacks knowledge of Upstart, so continues to operate on everything via the legacy sysvinit init scripts.

Puppet optionally can be told that the init script supports a "status" parameter, and then expects the init script to exit non-zero, per LSB 3.1

Currently, a service is using an Upstart job, but has the legacy initscript interface, the "status" parameter exits 0, regardless of the state of the service.

For example (using Lucid):

$ sudo /etc/init.d/gssd status
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service gssd status

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the status(8) utility, e.g. status gssd
gssd start/running, process 24250
$ echo $?
0
$ sudo /etc/init.d/gssd stop
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service gssd stop

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the stop(8) utility, e.g. stop gssd
gssd stop/waiting
$ sudo /etc/init.d/gssd status
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service gssd status

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the status(8) utility, e.g. status gssd
gssd stop/waiting
$ echo $?
0

Compare this with Postfix, which is not using Upstart:

$ echo $?
0
$ sudo /etc/init.d/postfix status
 * postfix is not running
$ echo $?
3
$ sudo /etc/init.d/postfix start
 * Starting Postfix Mail Transport Agent postfix [ OK ]
$ sudo /etc/init.d/postfix status
 * postfix is running
$ echo $?
0

There are similar issues with the Upstart-provided utilities:

$ sudo status gssd
gssd stop/waiting
$ echo $?
0
$ sudo service gssd start
gssd start/running, process 28011
$ sudo status gssd
gssd start/running, process 28011
$ echo $?
0

Obviously only services that have Upstart jobs are visible via this interface.

summary: - Lack of exit codes
+ initctl: lacks proper exit codes
Changed in upstart (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Changed in upstart:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

For sanity's sake, I'm closing the Ubuntu tasks for upstream Upstart bugs. I've experimented with having both, but it is just making bugs hard to find now. Will use the policy whereby bugs on the Ubuntu package exist in the Ubuntu packaging or patches only, any bugs in the Upstart code are Upstream bugs.

Changed in upstart (Ubuntu):
status: Triaged → Invalid
Revision history for this message
Mathias Gug (mathiaz) wrote :

Scott, do you think this bug can be fixed in time for Lucid release?

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote : Re: [Bug 552786] Re: initctl: lacks proper exit codes

On Sat, 2010-04-10 at 22:02 +0000, Mathias Gug wrote:

> Scott, do you think this bug can be fixed in time for Lucid release?
>
Since we're well past all relevant freezes, and this is not exactly a
show-stopping bug, I don't see how.

Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?

Revision history for this message
Mathias Gug (mathiaz) wrote :

On Sun, Apr 11, 2010 at 01:48:25AM -0000, Scott James Remnant wrote:
> On Sat, 2010-04-10 at 22:02 +0000, Mathias Gug wrote:
>
> > Scott, do you think this bug can be fixed in time for Lucid release?
> >
> Since we're well past all relevant freezes, and this is not exactly a
> show-stopping bug, I don't see how.
>

A broken use case is existing monitoring scripts (ex: bug 551544 - puppet
service provider). For an upstartified service '/etc/init.d/service status'
always returns zero. If the daemon dies the monitoring probe will not be able
to detect it and happily report that the daemon is running.

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

Revision history for this message
Steve Langasek (vorlon) wrote :

If a fix were available, I expect I would regard this as a bugfix-only change and allow it in for final.

If not, it might even be suitable for SRU.

Revision history for this message
Mathias Gug (mathiaz) wrote :

About which exit codes should be used:

< Keybuk> I guess 0 := goal = start & state = running
< Keybuk> anything else can be 1

Revision history for this message
Andrew Pollock (apollock) wrote :
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

On Tue, 2010-04-13 at 17:44 +0000, Andrew Pollock wrote:

> It probably makes sense to be consistent with
> http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-
> generic/iniscrptact.html, doesn't it?
>
No, there's no reason for Upstart to be consistent with the LSB if it
doesn't make sense -- I assume that LSB future will mandate Upstart,
after all.

For example, given the above return codes:

0 program is running or service is OK

   this one makes sense for Upstart

1 program is dead and /var/run pid file exists
2 program is dead and /var/lock lock file exists

   these make no sense for Upstart

3 program is not running

    "not running" is too vague; what about "is starting", "is being
    stopped" or "will be restarted" ?

4 program or service status is unknown

    service status can *never* be unknown with Upstart

Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?

Revision history for this message
Mathias Gug (mathiaz) wrote :

Agreed - in the long term.

For lucid I'd like to get the most important issue fixed: status service returns 0 if the daemon is *not* running.

Revision history for this message
Andrew Pollock (apollock) wrote :

I'm thinking about interoperability. If, for example, Lucid is going to continue to provide legacy init scripts for Upstart jobs, those legacy init scripts should continue to operate in as compatible a manner as possible.

Alternatively, don't provide legacy init scripts for things that have been converted to using Upstart, then you're free to avoid the current LSB spec for init scripts.

But what's there right now is not doing anybody any favours. Puppet, which is currently Upstart-unaware, sees the legacy init scripts and uses them, and they don't work in the expected way.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

On Tue, 2010-04-13 at 19:13 +0000, Andrew Pollock wrote:

> I'm thinking about interoperability. If, for example, Lucid is going to
> continue to provide legacy init scripts for Upstart jobs, those legacy
> init scripts should continue to operate in as compatible a manner as
> possible.
>
Yes, but this only says what "upstart-job" should emulate -- it doesn't
specify what status itself should return.

Also it's worth jumping up and down at this point and saying that
upstart-job should emulate Debian Policy *not* LSB (they conflict)

Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?

Revision history for this message
Dag Stenstad (dag-stenstad) wrote :

Well, I have another use case; Basically it breaks monitoring of processes in a cluster environment, as cluster software still doesn't support upstart. My cluster software is happily announcing that a service is running, even if it is stopped. This leads to a lot of breakage and pain. And lost data.

Revision history for this message
Dag Stenstad (dag-stenstad) wrote :

Wow, this is ugly. But kinda works:

# diff upstart-job /lib/init/upstart-job
45c45,47
< $COMMAND "$JOB"
---
> RESULT=$($COMMAND "$JOB")
> $ECHO $RESULT
> $ECHO $RESULT | grep -q -v "stop/waiting"

Revision history for this message
David Britton (dpb) wrote :

The following patch to service fixes it for precise. This may not be the most graceful, but this bug is really annoying. Could we get something pushed through?

121c121,128
< start|stop|status|reload)
---
> status)
> # Make sure status only succeeds in the started case
> result=`${ACTION} ${SERVICE} ${OPTIONS}`
> echo $result
> echo "$result" | grep -q "start/waiting"
> exit $?
> ;;
> start|stop|reload)

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Yeah, above patch will not work in saucy and up, as "upstart-job" symlink is deprecated, and service command correctly calls into upstart's status command to print status with upstart convention.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.