| bradleyayers | I'm a bit confused about what http://upstart.ubuntu.com/cookbook/#restarting-jobs-with-complex-conditions means | 01:41 |
|---|---|---|
| bradleyayers | I was under the impression that upstart tracked the state of jobs, and would start jobs when their conditions were met | 01:42 |
| bradleyayers | would the situation (in that link) be any different if a 'stop on …' was defined? | 01:43 |
| bradleyayers | would it be any different if 'respawn' was specified? | 01:44 |
| SpamapS | bradleyayers: upstart tracks the state of jobs, but it only changes their goal-state on events, not conditions. Its a subtle difference. | 06:29 |
| SpamapS | bradleyayers: that section is a bit ambiguous.. I'm going to propose a slight change. | 06:31 |
| 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:32 |
| bradleyayers | so then let's say X stops, then B stops | 06:33 |
| bradleyayers | what happens when i do 'start B' | 06:33 |
| * SpamapS draws it in his head | 06:39 | |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| bradleyayers | that's my understanding too | 06:47 |
| bradleyayers | starting is a 'method event' | 06:47 |
| bradleyayers | or probably 'hook' | 06:47 |
| 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:49 |
| bradleyayers | i'll read over bug #447654 | 06:50 |
| 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:51 |
| bradleyayers | i see | 06:52 |
| SpamapS | bradleyayers: the disconnect that nearly everyone experiences is that they are events, not states, and so are inherently ephemeral. | 06:54 |
| bradleyayers | yeah :( | 06:55 |
| bradleyayers | i get it now | 06:55 |
| bradleyayers | so this definitely hasn't been fixed yet? | 06:55 |
| SpamapS | No, it effectively needs a rewrite of the event loop to add the ability to observe states. | 06:57 |
| SpamapS | In practice, it can be worked around with the 'wait-for-state' job. | 06:58 |
| SpamapS | bradleyayers: is this your bug btw: https://bugs.launchpad.net/upstart-cookbook/+bug/912348 | 06:59 |
| bradleyayers | yeah that sums up what my question was | 07:00 |
| SpamapS | Cool, I just pushed up a merge proposal https://code.launchpad.net/~clint-fewbar/upstart-cookbook/clarify-complex-start-stop/+merge/90379 | 07:01 |
| 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:04 |
| SpamapS | bradleyayers: agreed on the bolding, pushed that up | 07:12 |
| bradleyayers | cool | 07:12 |
| bradleyayers | hey SpamapS thanks for the help before | 09:26 |
| === JanC_ is now known as JanC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!