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
>
>
>