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