[02:27] <danderson> Hello all.
[02:29] <danderson> I'm trying to puzzle out what the difference between 'expect fork' and 'expect daemon' is in an upstart config.
[02:30] <danderson> I'm writing a config for tpmd (TPM emulator daemon). When exec'd, it backgrounds itself. Using 'expect daemon' makes the start/stop commands hang, whereas 'expect fork' starts and stops the daemon as expected.
[02:30] <danderson> what is the actual difference between these two expects?
[02:32] <juan__> I'm not sure but this entry seams relevant http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/
[02:36] <danderson> well, that talks about daemons and how to track them in general. I'm more looking for the distinction upstart makes between 'fork' and 'daemon'.
[15:10] <drocko> hello
[15:10] <drocko> i'm trying to write an upstart job to run when my system starts up, but it never seems to run. I can run it after the system is booted and everything is fine, but i really need this to run at startup. Can someone help me out?
[15:12] <babel> I don't think you will get some helpful information here. I asked some question like you a few days ago without any help. maybe you should try the mailling list next ...
[15:12] <drocko> rats
[15:12] <drocko> have you made an upstart job that has worked at boot?
[15:12] <drocko> I feel like im missing something that is probably obvious
[15:13] <drocko> like is there a command that you have to run to notify upstart that there are new scripts in /etc/init ?
[15:14] <babel> i tried to create a job that should be started before kvm shutdown (i would like to shutdown some kvm guest gracefully). i was able to run the job fine via an emit event, but I wasn't able to find a way to invoke the script before kvm was killed.
[15:15] <drocko> hm
[15:15] <drocko> dang
[15:17] <babel> drocko: no, this is done via inotify (and there you shouldn't need such a tool or command)
[15:17] <drocko> yeah that is what i figured
[15:18] <drocko> so let me ask you another question
[15:18] <babel> the upstart doc is somewhat ...
[15:18] <drocko> when upstart runs these jobs, it's running them as root, right?
[15:18] <babel> as fas as i know, yes.
[15:18] <babel> far
[15:19] <drocko> http://pastebin.com/d40ca71b9
[15:19] <drocko> this is my job
[15:19] <drocko> and it works, just not on boot
[15:20] <babel> start on stopped rc[2345] -> start on runleven[2345]
[15:21] <babel> runlevel
[15:21] <drocko> I'll try that
[15:21] <drocko> i dunno
[15:24] <drocko> wow, thanks babel. that worked!
[15:25] <drocko> also it means that this bullshit answer is totally wrong: https://answers.launchpad.net/upstart/+question/83223
[15:26] <babel> maybe.
[15:26] <drocko> yes
[15:26] <drocko> maybe 
[15:26] <drocko> it's all voodoo
[15:26] <babel> now, better docs would help.
[15:26] <drocko> yeah, you know it's the same problem with grub2
[15:26] <drocko> like
[15:26] <babel> and something to make a dry-run
[15:26] <drocko> people think that a wiki would like really be great for documentation
[15:26] <drocko> because everyone could read it and contribute
[15:27] <drocko> but really it turns into like
[15:27] <babel> if the wiki is up to date that's true but.
[15:27] <drocko> a collection of cryptic notes 
[15:27] <drocko> right
[15:27] <drocko> that are out of date
[15:28] <Keybuk> the trouble is, very few people are good at writing good documentation :)
[15:29] <Keybuk> danderson: the difference is how many forks upstart expects ;)
[15:29] <Keybuk> "expect fork" means Upstart counts one fork()
[15:29] <Keybuk> "expect daemon" means Upstart counts two fork()s
[15:29] <danderson> aaah.
[15:29] <danderson> I see.
[15:29] <Keybuk> to "properly" daemonise, a process needs to fork twice
[15:29] <danderson> so, this daemon I have isn't actually daemonizing properly, just forking into the background
[15:29] <Keybuk> of course, most things don't properly daemonise, so just "expect fork" is enough
[15:30] <danderson> right, I know; I assumed that the author of the software knew that as well :-)
[15:30] <Keybuk> the fact you need to be careful is because we use ptrace() to track this stuff
[15:30] <Keybuk> which is so less than ideal it's not even funny
[15:30] <danderson> (I'm just building an ubuntu package for his software, and writing the appropriate upstart config)
[15:30] <danderson> ouch ptrace().
[15:31] <danderson> but yeah, I don't see any other way to figure that out :(
[15:31] <Keybuk> there are some good new ways
[15:31] <Keybuk> kernel proc events and stuff
[15:32] <danderson> hmm, is the wiki read/write?
[15:32] <Keybuk> yes
[15:32] <danderson> perhaps I should try to start a "configuration writing manual" with some of this knowledge
[15:32] <sadmac> Keybuk: kernel proc events? Is that something new? reading material?
[15:33] <Keybuk> sadmac: proc connector, proc events, proc stats
[15:33] <Keybuk> just different names for the same thing
[15:33] <sadmac> Keybuk: ah
[15:35] <danderson> oh, and also, while people are around: woot upstart, thank you for building it! It's so much saner than futzing with init scripts it's unbelievable.
[15:39] <drocko> hm
[15:39] <drocko> alright so next challenge. my job runs at boot, but it needs to have the network up and running for it to be successful. how can i build in a dependency like that?
[15:42] <babel> try start on net-device-up
[15:43] <drocko> should i remove the start on runlevel [2345] or should I use both?
[15:43] <drocko> like start on (runlevel [2345]
[15:43] <drocko> and net-device-up)
[15:43] <drocko>  ?
[15:45] <babel> just start on net-device-up
[15:45] <babel> since you only depend on these event.
[15:46] <drocko> alright let's see what happened
[16:18] <drocko> babel2: thanks for the help. i think I got it sorted
[16:18] <babel2> no problem, share your knowlegde next time with some newbie :)
[16:19] <drocko> yeah definitelty
[16:19] <drocko> upstart is cleaner than like launchd on OS X and makes a little more sense than svcs on solaris, but like the documentation has to get there
[16:19] <drocko> Maybe i'll add what i've found to the wiki
[17:28] <mbiebl> Keybuk: around?
[17:29] <Keybuk> yus
[17:29] <mbiebl> having a problem with karmic and bridge devices
[17:30] <mbiebl> the system in question has two bridge devices configured
[17:30] <mbiebl> which are attached to kvm instances
[17:30] <Keybuk> yeah they don't work
[17:30] <mbiebl> ah, ok
[17:31] <mbiebl> seems the libvirt-bin init script tries to start the kvm instances beforce br0 and br1 are up
[17:32] <Keybuk> yes
[17:32] <mbiebl> Keybuk: is there a solution available?
[17:32] <Keybuk> actually nothing brings up br0 and br1
[17:32] <Keybuk> not that I know of
[17:33] <mbiebl> well, the devices are available after some time and if I add a sleep 30 inside the libvirt-bin init script, I can get it to work
[17:33] <mbiebl> this is of course fugly
[17:57] <wasabi> is there an event when br* comes up?
[17:57] <wasabi> net-device-added seems to be setup
[17:59] <ion> net-device-up, /etc/network/if-up.d/upstart
[17:59] <wasabi> ahh there iti s
[17:59] <wasabi> was wondering who was emitting it
[17:59] <mbiebl> I havea network-interface (br0) start/running
[17:59] <mbiebl> and the same for br1
[17:59] <wasabi> I'm kind of working on the same, with init scripts for virtualbox.
[18:00] <wasabi> Haven't yet tackled this. ;0
[19:33] <mbiebl> Keybuk: still around?