[14:16] <steffen_b> having trouble to understand instance handling 
[15:28] <SpamapS> steffen_b: its fairly simple if you consider that all jobs start with an instance value of ""
[15:29] <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:30] <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:31] <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:32] <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:33] <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:34] <steffen_b> i have Xorg (job called openbox) and i have vdr (job called vdr) 
[15:35] <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:36] <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:37] <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:38] <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:39] <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:40] <steffen_b> in post-start ?
[15:41] <SpamapS> no you don't need a post-start if you use expect stop
[15:42] <SpamapS> I don't know of any jobs that use that method right now btw
[15:43] <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:44] <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:45] <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:49] <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:52] <steffen_b> might be worth a try - allthough we just added something to emit an event from daemon 
[15:53] <steffen_b> sounds like a way to keep it on one place 
[16:01] <SpamapS> steffen_b: emitting an event is fine too, its actually pretty cool. :)
[16:02] <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:09] <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:10] <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:11] <steffen_b> so migrating depending jobs to be user jobs 
[16:13] <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:14] <steffen_b> it never forks i think 
[16:14] <steffen_b> i have no expect currently and it works :)
[16:15] <steffen_b> its tracing the right thing 
[16:20] <steffen_b> to know when its ready we using a plugin to the daemon which signals us from the first loop after initializing
[16:21] <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:22] <steffen_b> the systemd kind of handling it 
[16:22] <steffen_b> yes
[16:22] <steffen_b> noch socket activation but buffering 
[16:23] <steffen_b> noch -> not
[16:23] <steffen_b> that would simply the thing i try by 50%
[16:24] <SpamapS> I don't like socket activatino
[16:24] <SpamapS> it simplifies the thinking, but not necessarily the implementation
[16:26] <steffen_b> there are few things which are cool in theory - but in reality you need to workaround more things than you like
[16:27] <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:28] <steffen_b> if that expect is state-like 
[16:29] <SpamapS> it doesn't need to be state based
[16:30] <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:34] <steffen_b> states are more natural
[16:36] <SpamapS> are they?
[16:36] <steffen_b> 100%
[16:37] <SpamapS> Also, upstart *is* state based
[16:37] <JanC> states & events need each other, so one isn't natural without the other
[16:38] <SpamapS> you can track states w/ jobs
[16:38] <steffen_b> but you need inictl status <jobname> | grep -q "^jobname.*running" 
[16:39] <steffen_b> in an upstart job 
[16:39] <steffen_b> where are the states at this point ?
[16:45] <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:46] <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:47] <steffen_b> wasn't that the workaround for "starting ... or starting ..." second one did not wait anymore ?
[16:48] <steffen_b> until job is started
[16:50] <SpamapS> yeah, well, thats basically the same problem
[16:54] <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  ;)