| steffen_b | having trouble to understand instance handling | 14:16 |
|---|---|---|
| SpamapS | steffen_b: its fairly simple if you consider that all jobs start with an instance value of "" | 15:28 |
| SpamapS | steffen_b: the instance keyword just expands that a bit so that there can be multiple instances of a job if need be, by introducing variables | 15:29 |
| steffen_b | yes - but i can stop a single instance by "stop on " condition ? | 15:29 |
| SpamapS | steffen_b: all instances will stop based on the stop on, though you can use the same variables in the stop on as you do in instance | 15:30 |
| SpamapS | steffen_b: so if you have 'instance $FOO' and 'stop on stopping other-job FOO=$FOO' that works | 15:30 |
| steffen_b | yes - guess what i tried was just bad idea | 15:31 |
| steffen_b | i wanted to track 2 events and making instance for each | 15:31 |
| steffen_b | if both happened (state saved in instance) | 15:31 |
| SpamapS | steffen_b: for what purpose? | 15:31 |
| steffen_b | i can start something else | 15:32 |
| SpamapS | so like 'start on started something-state EVENT=foo and started something-state EVENT=bar' ? | 15:32 |
| steffen_b | logically yes | 15:33 |
| steffen_b | except upstart doesnt work like that | 15:33 |
| SpamapS | well, it might, I think we're far too abstract. | 15:33 |
| SpamapS | can you be more concrete? | 15:33 |
| steffen_b | i have Xorg (job called openbox) and i have vdr (job called vdr) | 15:34 |
| steffen_b | each emits an upstart event openbox-started vdr-started once really completed | 15:35 |
| SpamapS | you know upstart does that for you | 15:35 |
| SpamapS | right? | 15:35 |
| steffen_b | maybe on paper | 15:35 |
| SpamapS | no it does it, in code. :) | 15:35 |
| steffen_b | not really believe me | 15:35 |
| SpamapS | Somehow we've managed to get upstart to do that to boot Ubuntu :) | 15:36 |
| SpamapS | now, perhaps you're not familiar with some of the idiosyncratic ways to control the timing of that event emission | 15:36 |
| steffen_b | a daemon forking doesnt mean its ready to connect | 15:36 |
| SpamapS | *agreed 100%* | 15:36 |
| SpamapS | thats why we have post-start | 15:36 |
| SpamapS | 'started' is not emitted until post-start exits | 15:37 |
| steffen_b | i only know from inside the daemon, once completed | 15:37 |
| steffen_b | now tell me how i get this outside | 15:37 |
| steffen_b | and use it in post start | 15:37 |
| SpamapS | touch a file | 15:38 |
| SpamapS | while ! [ -f $file ] ; do ... | 15:38 |
| steffen_b | and loop sleep 1 ? | 15:38 |
| SpamapS | or open a socket | 15:38 |
| SpamapS | or a fifo.. | 15:38 |
| SpamapS | lots of ways to do it | 15:38 |
| steffen_b | except the famous while ... sleep ... there is still no way | 15:39 |
| SpamapS | also you can use 'expect stop' | 15:39 |
| SpamapS | and send yourself SIGSTOP | 15:39 |
| SpamapS | upstart will send you SIGCONT and the emit started | 15:39 |
| steffen_b | in post-start ? | 15:40 |
| SpamapS | no you don't need a post-start if you use expect stop | 15:41 |
| SpamapS | I don't know of any jobs that use that method right now btw | 15:42 |
| SpamapS | looping or using a fifo in post-start is the only method I've seen really | 15:43 |
| steffen_b | at the moment i have start on started vdr and in the client i loop until socket is availble | 15:43 |
| steffen_b | which is painfull since this adds up to plenty of loops waiting and still keep them sort of syncronized in different cases | 15:44 |
| SpamapS | is that a local socket? | 15:44 |
| SpamapS | because, if its ever intended to be over a network, you should probably just keep that strategy.. you can't coordinate events over the network ;) | 15:44 |
| SpamapS | at least, not w/ upstart :p | 15:45 |
| steffen_b | local network, local fd, dbus ... | 15:45 |
| steffen_b | x | 15:45 |
| steffen_b | sound | 15:45 |
| SpamapS | steffen_b: yeah, post-start seems like the simplest way forward, but if you want to build in upstart support, use the 'expect stop' method described in 'man 5 init | 15:49 |
| steffen_b | might be worth a try - allthough we just added something to emit an event from daemon | 15:52 |
| steffen_b | sounds like a way to keep it on one place | 15:53 |
| SpamapS | steffen_b: emitting an event is fine too, its actually pretty cool. :) | 16:01 |
| SpamapS | steffen_b: also, I believe there is a new initiative to track exits, not just forks, so that daemons that do the right thing and keep the parent alive until the service is ready, will work fine | 16:02 |
| steffen_b | well there is also some fight with emitting an event as well | 16:09 |
| steffen_b | daemon is running as user - upstart event is send from user over dbus | 16:09 |
| steffen_b | since inclusion of user jobs this means you can not control system jobs from user (except you switch that off i guess) | 16:10 |
| steffen_b | so migrating depending jobs to be user jobs | 16:11 |
| steffen_b | where this user jobs are jobs of a system user - doesnt really sound like something which should be handed to the user | 16:13 |
| steffen_b | guess a step back and think again | 16:13 |
| SpamapS | steffen_b: sounds like another reason to think about expect stop | 16:13 |
| steffen_b | yes | 16:13 |
| SpamapS | steffen_b: does your daemon keep its parent alive until it is ready? | 16:13 |
| steffen_b | it never forks i think | 16:14 |
| steffen_b | i have no expect currently and it works :) | 16:14 |
| steffen_b | its tracing the right thing | 16:15 |
| steffen_b | to know when its ready we using a plugin to the daemon which signals us from the first loop after initializing | 16:20 |
| steffen_b | so vdr and upstart dont like each other | 16:21 |
| SpamapS | ah ok | 16:21 |
| SpamapS | I do kind of wish we could have something like 'expect socket /var/run/foo.sock' | 16:21 |
| steffen_b | the systemd kind of handling it | 16:22 |
| steffen_b | yes | 16:22 |
| steffen_b | noch socket activation but buffering | 16:22 |
| steffen_b | noch -> not | 16:23 |
| steffen_b | that would simply the thing i try by 50% | 16:23 |
| SpamapS | I don't like socket activatino | 16:24 |
| SpamapS | it simplifies the thinking, but not necessarily the implementation | 16:24 |
| steffen_b | there are few things which are cool in theory - but in reality you need to workaround more things than you like | 16:26 |
| steffen_b | expect /dev/foo | 16:27 |
| steffen_b | expect tcp://localhost:37890 | 16:27 |
| steffen_b | expect /tmp/foo | 16:27 |
| steffen_b | would for sure make things simpler | 16:27 |
| steffen_b | if that expect is state-like | 16:28 |
| SpamapS | it doesn't need to be state based | 16:29 |
| SpamapS | just treat the appearance of a file/socket/etc. as an event | 16:30 |
| SpamapS | and then we can use a job to track its state | 16:30 |
| steffen_b | states are more natural | 16:34 |
| SpamapS | are they? | 16:36 |
| steffen_b | 100% | 16:36 |
| SpamapS | Also, upstart *is* state based | 16:37 |
| JanC | states & events need each other, so one isn't natural without the other | 16:37 |
| SpamapS | you can track states w/ jobs | 16:38 |
| steffen_b | but you need inictl status <jobname> | grep -q "^jobname.*running" | 16:38 |
| steffen_b | in an upstart job | 16:39 |
| steffen_b | where are the states at this point ? | 16:39 |
| steffen_b | anyway - this is not blaming or being negative - just sharing thougts hope you dont get it wrong :) | 16:45 |
| SpamapS | steffen_b: that *is* the state :) | 16:45 |
| steffen_b | :D | 16:46 |
| SpamapS | if you look on a recent ubuntu system, you'll see the workaround for not having them built in.. /etc/init/wait-for-state.conf | 16:46 |
| SpamapS | start wait-for-state WAITER=me WAIT_FOR=somejob | 16:46 |
| SpamapS | that lets you use jobs like condition variables basically | 16:46 |
| steffen_b | wasn't that the workaround for "starting ... or starting ..." second one did not wait anymore ? | 16:47 |
| steffen_b | until job is started | 16:48 |
| SpamapS | yeah, well, thats basically the same problem | 16:50 |
| JanC | maybe what we really need is an init daemon that can be configured with low-level state/event instructions, and then write compilers that turn all sort of job/unit/initscripts/... in config for it ;) | 16:54 |
| === SpamapS_ is now known as SpamapS | ||
| === bradleyayers_ is now known as bradleyayers | ||
| === alienth_ is now known as alienth | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!