[01:17] <joern> i may be stupid or blind, but somehow i cannot find documentation about when exactly "emits" is processed
[01:18] <joern> is it before the exec, directly after the exec, a second later,...?
[01:18] <broder> "emits" is just metadata - it doesn't cause an event to get emitted
[01:18] <broder> (it's intended to annotate, e.g., "the executable i'm about to call is going to emit these events at some point")
[01:19] <broder> it's used by things like initctl show-config and initctl check-config for verification
[01:19] <joern> so the executable has to do whatever initialization and then somehow emit this event
[01:19] <broder> but if you want to emit some event, you should use initctl emit in the exec/script line
[01:19] <joern> ok
[01:20] <joern> and for "started foo", when is that event generated?
[01:20] <broder> that's emitted when the job changes states from "starting" to started
[01:20] <broder> when that happens depends on the expect line and whether it's marked as a task or not
[01:20] <broder> possibly other things, too
[01:21] <joern> so with "expect fork", as soon as fork(2) returns, i take it?
[01:22] <broder> or possibly when fork is called. i don't recall
[01:23] <joern> i would imagine there could be nasty race conditions then - although very hard to hit
[01:24] <joern> anyway, thanks!  i believe i have enough rope to hang myself now
[01:24] <broder> well, you just have to make sure your daemon is actually ready whenever you trigger that transition
[01:24] <broder> so do all your setup (binding to ports, setting signal handlers) before you fork
[01:25] <joern> and maybe spend a night reading all existing /etc/init/*.conf files before writing my own
[01:26] <broder> if you're writing a daemon/binary targeted at upstart specifically, i'm a fan of "expect stop"
[01:26] <broder> then you just do "raise(SIGSTOP);" whenever you're done with setup
[01:28] <joern> i would actually like not to have any dependencies on upstart.  we currently have tons of subtle dependencies and my unwritten job description is to find them all and remove them - or at least make them explicit
[01:28] <joern> would be nice if i was the last person to suffer this pain
[01:29] <broder> you should check out the upstart cookbook, btw, if you haven't
[01:50] <joern> 4.3.1 seems to be the answer to most of my questions.  thanks!
[18:07] <lamal666> Hi, im trying to write an upstart job to execute a script but when i run it- nothing happens
[18:09] <lamalex> http://paste.ubuntu.com/770327/
[18:10] <lamalex> ha clearly i cp'd another conf file..
[18:10] <lamalex> sudo start coverity 
[18:10] <lamalex> coverity start/running, process 2518
[18:10] <lamalex> is what i get
[18:11] <lamalex> but the server doesn't really start
[18:13] <ion> http://upstart.ubuntu.com/cookbook/#obtaining-a-log-of-a-script-section
[18:15] <lamalex> ion, so i dont have a script stanza- i just have exec
[18:15] <lamalex> can i just put this above the exec line
[18:15] <lamalex> or do i need script stanza
[18:18] <xaka> hi! is anyone from dev team here?
[18:22] <ion> lamalex: Change
[18:22] <ion> exec foo
[18:22] <ion> to
[18:22] <ion> script
[18:22] <ion>   exec >/path/to/log 2>&1
[18:22] <ion>   set -x
[18:22] <ion>   exec foo
[18:22] <ion> end script
[18:28] <lamalex> ion, also is it possible to write a custom stop job?
[18:28] <ion> Use pre-stop.
[18:30] <lamalex> ah cool thanks
[18:33] <xaka> is there any way to specify dependencies? like i want to start service A on runlevel 2345, but after service B has been started
[18:35] <ion> A: start on started B, stop on stopping B
[18:35] <ion> B: start on runlevel [2345], stop on runlevel [!2345]