init: stopping and stopped should indicate if job is to be respawned
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
upstart |
Triaged
|
Wishlist
|
Unassigned |
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 affecting 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
description: | updated |
description: | updated |
summary: |
- respawned jobs go to "stopping" with "RESULT=ok" and no way to detect - respawn + init: stopping and stopped should indicate if job is to be respawned |
Changed in upstart: | |
status: | New → Triaged |
importance: | Undecided → Wishlist |
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: /bugs.launchpad .net/bugs/ 716802
>
> 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:/
>
> 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 h...