[12:01] is it possible to have upstart start job b if job a failed? [12:10] yes [12:19] hi [12:21] mdales: the stopping and stopped events have arguments saying that it failed, what failed and why [12:21] ah, excellent [12:21] is that in the version that's in gutsy? [12:22] I was reading up on jobfailedevent, but I assume that's not there at the moment. [12:22] thanks for the info [12:23] it's there [12:23] job-failed-event was implemented in 0.3.x [12:23] ah [12:23] w00t [12:33] I have a job that was started and exite sucessfully , it is not a rewawn job , but I would like the job to remain in "start(ed)" status or at least would like to know that is was started [12:33] (I currently have a while sds ; sleep 10 ; to keep it running [12:53] I'm not sure I follow [12:54] :P [12:55] you have a job [12:55] and you want that job to always be running? [12:56] what I really want to know is if is was stated regardless of whether it is still running [12:56] if it was started, the goal will always be start? [12:57] much like the mount-kernel-filesystem job [12:57] usual way for that kind of thing is to put the work in the pre-start bit of the job [12:57] Keybuk: what is the "goal" of a job? [12:58] spore scott% sudo status tty1 [12:58] tty1 (start) running, process 4576 [12:58] the goal is start, which means Upstart will attempt to keep the job running [12:58] if the goal is stop, Upstart will attempt to keep the job _from_ running [12:58] goal is changed to start by events or manual command [12:59] goal is changed to stop by events, manual command and the main process exiting (unless respawn and not normal exit) [12:59] yes but I don't want it to be running, even if I call start mount-kernel-filesystems [13:00] jdong: I was thinking about whether there should be the option of "sticky" jobs [13:00] that stayed running even after the process exited [13:00] but I couldn't decide whether that was any different from what you were doing, and just doing the work in pre-start [13:00] after that (because the jobs is no respawn) the status is stop [13:00] I would like it to be something else :p [13:01] respawn would keep it at start [13:01] (though you would still get stopping/stopped/starting/started events each time it exited) [13:02] but I don't want that. I want the job to finish gracefully and the status to remain on something else then "stopped" [13:02] the best way to do that is to put your "job" in pre-start [13:02] it'll be run when you start the job, and the job will stay in running (since there's no script/exec) until otherwise stopped [13:03] the that sounds very sexy! [13:03] let me try that! [13:09] it's an interesting pattern [13:27] I can not say how happy I am ! it is working! [13:37] well kinda ... [13:40] apparently I can not simply start such a service using emit (with no --no-wait) [13:40] perhaps it is missing some events [13:40] start? [13:40] * Keybuk really must fix that confusion [13:41] if you have /etc/event.d/foo [13:41] then the right way to start it is just "start foo" [13:41] emit foo won't do anything unless foo has "start on foo" in its job definition [13:47] yes , I have things like start on start_boot_mode_select [14:02] also with start foo I have to use --no-wait, , I am using 0.3.8 === kylem_ is now known as kylem === keesj_ is now known as keesj