On Mon, 2014-01-06 at 22:45 -0500, Stéphane Graber wrote: > On Mon, Jan 06, 2014 at 09:32:33PM -0600, Ted Gould wrote: > > It seems like most of the examples in the Cookbook recommend that if you > > want to stop a job in the pre-start stanza, you should call "stop" which > > will handle stopping the job for you. But, it seems looking at the > > Upstart code I can just as easily return a negative return value to > > cause the job to stop: > > > > http://bazaar.launchpad.net/~upstart-devel/upstart/trunk/view/head:/init/job.c#L417 > > > > Is there a reason I should call "stop" over just returning a negative > > value? > > Calling { stop; exit 0; } also means the job won't be considered as failed. > > Returning non-zero will log an error in the log file and prevent any job > depending on the current job from starting (which may or may not be what > you want). > > So in short, exitting non-zero or calling stop+exit are two different > things with different behaviours, you have to choose which you want.
Interesting, I didn't realize all of the implications there. I thought that a stopped signal wasn't sent if a job was never started, and failing in pre-start would mean that it was never started. So how would "failed" be tracked in this case? There's no way to get an event "stopped foo RESULT=failed"? It seems like jobs that have instances don't track failed in any visible way? Also, will a failed pre-start trigger a respawn? Going down the rabbit hole, Ted
signature.asc
Description: This is a digitally signed message part
-- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
