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