Comment 1 for bug 716802

Respawn jobs have:

  stop on stopping bar PROCESS=respawn

did this not work for you?

Scott

On Thu, Feb 10, 2011 at 4:51 PM, Matt Cowell <email address hidden>wrote:

> Public bug reported:
>
> Say I have two jobs: foo and bar. bar is marked "respawn" and provides
> some service used by 'foo'. foo is marked "stop on stopping bar" so
> that it will stop when bar is no longer available. bar does not
> maintain any state, so that if it crashes, it can safely be respawned
> without effecting the functionality of foo.
>
> The problem is that I need a way here to determine if 'bar' crashed and
> was respawned, or just was actually stopped using the "stop" command. A
> job which will be respawned is not marked as failed unless it is
> respawning too fast, and the "stopping" event is still sent with
> "RESULT=ok", just as it would be if it were stopped using "stop" or
> "stop on", never to come back.
>
> It would be beneficial to provide either another value for "RESULT" or
> another environment variable which indicates whether the stopping event
> is due to a respawn. It could then be used in the following manner
> (using my foo/bar example above -- showing foo):
>
> stop on stopping bar RESULT!=respawn
>
> -or-
>
> stop on stopping bar RESPAWN!=yes
>
> ** Affects: upstart
> Importance: Undecided
> Status: New
>
> ** Description changed:
>
> Say I have two jobs: foo and bar. bar is marked "respawn" and provides
> some service used by 'foo'. foo is marked "stop on stopping bar" so
> that it will stop when bar is no longer available. bar does not
> maintain any state, so that if it crashes, it can safely be respawned
> without effecting the functionality of foo.
>
> The problem is that I need a way here to determine if 'bar' crashed and
> was respawned, or just was actually stopped using the "stop" command. A
> job which will be respawned is not marked as failed unless it is
> respawning too fast, and the "stopping" event is still sent with
> "RESULT=ok", just as it would be if it were stopped using "stop" or
> "stop on", never to come back.
>
> It would be beneficial to provide either another value for "RESULT" or
> another environment variable which indicates whether the stopping event
> is due to a respawn. It could then be used in the following manner
> (using my foo/bar example above -- showing foo):
>
> stop on stopping bar RESULT!=respawn
>
> -or-
>
> - stop on stopping bar RESPAWN=yes
> + stop on stopping bar RESPAWN!=yes
>
> --
> You received this bug notification because you are a member of Upstart
> Developers, which is subscribed to upstart .
> https://bugs.launchpad.net/bugs/716802
>
> Title:
> respawned jobs go to "stopping" with "RESULT=ok" and no way to detect
> respawn
>
> Status in Upstart:
> New
>
> Bug description:
> Say I have two jobs: foo and bar. bar is marked "respawn" and
> provides some service used by 'foo'. foo is marked "stop on stopping
> bar" so that it will stop when bar is no longer available. bar does
> not maintain any state, so that if it crashes, it can safely be
> respawned without effecting the functionality of foo.
>
> The problem is that I need a way here to determine if 'bar' crashed
> and was respawned, or just was actually stopped using the "stop"
> command. A job which will be respawned is not marked as failed unless
> it is respawning too fast, and the "stopping" event is still sent with
> "RESULT=ok", just as it would be if it were stopped using "stop" or
> "stop on", never to come back.
>
> It would be beneficial to provide either another value for "RESULT" or
> another environment variable which indicates whether the stopping
> event is due to a respawn. It could then be used in the following
> manner (using my foo/bar example above -- showing foo):
>
> stop on stopping bar RESULT!=respawn
>
> -or-
>
> stop on stopping bar RESPAWN!=yes
>
>
>