initctl: lacks proper exit codes

Reported by Andrew Pollock on 2010-03-31
86
This bug affects 15 people
Affects Status Importance Assigned to Milestone
upstart
Medium
Unassigned
upstart (Ubuntu)
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

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
Mathias Gug (mathiaz) wrote :

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

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?

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

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.

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

Andrew Pollock (apollock) 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?

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.

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.

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?

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.

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"

David Britton (davidpbritton) 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)

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  Edit
Everyone can see this information.

Other bug subscribers