Comment 2 for bug 716802
Revision history for this message
| Matt Cowell (matthew-cowell) wrote Re: [Bug 716802] [NEW] respawned jobs go to "stopping" with "RESULT=ok" and no way to detect respawn | #2 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
That doesn't work for doing what I am looking for. PROCESS is not set, as
respawn jobs are not marked as failed until the respawn limit is hit. I
always get "RESULT=ok" for "stopping" on a crash of a process which is
respawned. As far as I can tell, this code doesn't set it to failed unless
the respawn limit is hit:
http://
Also, from the documentation, PROCESS=respawn occurs "to indicate that the
job is stopping because it hit the respawn limit." I'm not looking to
detect the respawn limit here, just a single respawn.
Thanks,
-Matt
On Thu, Feb 10, 2011 at 19:33, Scott James Remnant <
<email address hidden>> wrote:
> 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:/
> >
> > 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
> >
> >
> >
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> 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 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
>
> To unsubscribe from this bug, go to:
> https:/
>