[01:41] <bradleyayers> I'm a bit confused about what http://upstart.ubuntu.com/cookbook/#restarting-jobs-with-complex-conditions means
[01:42] <bradleyayers> I was under the impression that upstart tracked the state of jobs, and would start jobs when their conditions were met
[01:43] <bradleyayers> would the situation (in that link) be any different if a 'stop on …' was defined?
[01:44] <bradleyayers> would it be any different if 'respawn' was specified?
[06:29] <SpamapS> bradleyayers: upstart tracks the state of jobs, but it only changes their goal-state on events, not conditions. Its a subtle difference.
[06:31] <SpamapS> bradleyayers: that section is a bit ambiguous.. I'm going to propose a slight change.
[06:32] <bradleyayers> so say i have a job X that "start on started A and started B", and "stop on stopping A or stopping B". A starts, then B starts, so 'started JOB=B' would be emitted, which would cause X to start right?
[06:32] <bradleyayers> then B changes its goal to stopped, so 'stopping JOB=B' would be emitted, which would cause X to change its goal to stopped, right?
[06:33] <bradleyayers> so then let's say X stops, then B stops
[06:33] <bradleyayers> what happens when i do 'start B'
[06:39]  * SpamapS draws it in his head
[06:40] <SpamapS> bradleyayers: it blocks
[06:40] <SpamapS> bradleyayers: until started A is emitted
[06:40] <bradleyayers> you mean started X?
[06:40] <SpamapS> no
[06:40] <bradleyayers> :O
[06:41] <SpamapS> because it is started A and started B ...
[06:41] <SpamapS> the and blocks
[06:41] <SpamapS> which is why and's require careful consideration
[06:41] <bradleyayers> oh okay, so B starts fine
[06:41] <SpamapS> bug #447654
[06:41] <bradleyayers> but then A stays with its goal as stopped
[06:41] <bradleyayers> aaa
[06:41] <bradleyayers> awit
[06:42] <bradleyayers> !!!
[06:42] <bradleyayers> Z stays with its goal as stopped**
[06:42] <bradleyayers> X
[06:42] <SpamapS> we had no Z!
[06:42] <bradleyayers> i know :(
[06:42] <SpamapS> ok
[06:42] <bradleyayers> I'll start again
[06:42] <SpamapS> yes X stays with its goal as stopped
[06:42] <bradleyayers> B starts properly
[06:42] <bradleyayers> then X stays with its goal as stopped
[06:42] <SpamapS> and perhaps more importantly, the started event for B is not "finished".. its blocking
[06:43] <SpamapS> so while B is started, the 'start' command (or event) will be waiting
[06:43] <SpamapS> There are times where this doesn't matter
[06:43] <SpamapS> you can use 'and' freely when the events that you are 'and'ing are never waited for
[06:44] <bradleyayers> but how can 'started' ever block, it's an event
[06:44] <SpamapS> for instance, the 'filesystem' event or the 'net-device-up' events aren't waited on
[06:44] <SpamapS> bradleyayers: ALL events can block
[06:44] <SpamapS> it is critical to the proper sequencing of the boot
[06:44] <bradleyayers> http://upstart.ubuntu.com/cookbook/#event-types says Signals don't block
[06:45] <SpamapS> for instance, the starting event needs to block, so that whatever you're trying to start before, doesn't start until you yourself are started
[06:45] <bradleyayers> which 'started' is
[06:45] <SpamapS> bradleyayers: signals aren't waited on.. but they actuall do still block.. :-/
[06:45] <bradleyayers> i should have said: "but how can 'started' ever block, it's a *signal*"
[06:45] <SpamapS> actually I should say
[06:45] <bradleyayers> ah okay, i didn't realise there was a difference between block and waited on :/
[06:45] <bradleyayers> my misunderstanding
[06:46] <SpamapS> started is not a signal
[06:46] <SpamapS> well it might be actually
[06:46] <SpamapS> I suppose it is since nothing is waiting for it.
[06:46] <SpamapS> starting, however, is always waited on
[06:47] <bradleyayers> that's my understanding too
[06:47] <bradleyayers> starting is a 'method event'
[06:47] <bradleyayers> or probably 'hook'
[06:49] <bradleyayers> so back to my original scenario, 'starting B' would be emitted, i dont understand why that doesn't trigger X's condition to be re-evaluated
[06:50] <bradleyayers> i'll read over bug #447654
[06:51] <SpamapS> bradleyayers: the condition is evaluated, and B's event satisfies only one side of it.
[06:51] <SpamapS> bradleyayers: since it is an and, you need to have A's started event *again*
[06:52] <bradleyayers> i see
[06:54] <SpamapS> bradleyayers: the disconnect that nearly everyone experiences is that they are events, not states, and so are inherently ephemeral.
[06:55] <bradleyayers> yeah :(
[06:55] <bradleyayers> i get it now
[06:55] <bradleyayers> so this definitely hasn't been fixed yet?
[06:57] <SpamapS> No, it effectively needs a rewrite of the event loop to add the ability to observe states.
[06:58] <SpamapS> In practice, it can be worked around with the 'wait-for-state' job.
[06:59] <SpamapS> bradleyayers: is this your bug btw: https://bugs.launchpad.net/upstart-cookbook/+bug/912348
[07:00] <bradleyayers> yeah that sums up what my question was
[07:01] <SpamapS> Cool, I just pushed up a merge proposal https://code.launchpad.net/~clint-fewbar/upstart-cookbook/clarify-complex-start-stop/+merge/90379
[07:04] <bradleyayers> i'd probably bold "is not known to upstart"
[07:04] <bradleyayers> but otherwise it looks good
[07:04] <bradleyayers> but a bit hard to be objective now that I actually understand it
[07:12] <SpamapS> bradleyayers: agreed on the bolding, pushed that up
[07:12] <bradleyayers> cool
[09:26] <bradleyayers> hey SpamapS thanks for the help before
=== JanC_ is now known as JanC