[02:21] <xnox> SegFaultAX: can you file a bug against upstart with example process that does that?
[11:04] <adrien_oww> is there a difference between writing "start on started B" in event.d/A and writing "start on starting A" in event.d/B?
[11:49] <xnox> adrien_oww: yes. if jobA.conf has "start on started B" then jobA will be automatically attempted to be started when jobB is fully started & running. and it doesn't matter how jobB has started (manually or automatically)
[11:50] <xnox> adrien_oww: if jobB.conf has "start on starting A", then just before jobA is attempted to be started it will be blocked until jobB fully starts.
[11:51] <xnox> in practice, you'd need additional stanzas in either of them to be automatically started, unless you intend to only start them manually.
[11:52] <xnox> this does not convey "state", since e.g. in "started B" case i can do manually start job A without having started job B.
[11:52] <xnox> in "start on starting A" case I can manually start job B and job A will not start.
[11:55] <xnox> adrien_oww: if B must be running, before A's main process is started, make sure in A pre-start script a check is made that B's state is correct. e.g. status B | grep -q start/running
[12:52] <adrien_oww> right, I see, thanks
[12:52] <adrien_oww> these scripts should only be started at boot so it won't matter much iiuc
[12:53] <adrien_oww> this is a fairly old codebase (well, up to 3-4 years) with an upstart 0.3.3 and I'm trying to start a process earlier on without changing too many things but I must have a line wrong
[13:15] <xnox> adrien_oww: i see. well, 0.3.3 sounds rather very old. I'd recommend upgrading if that is at all possible =) in recent upstarts there is an initctl2dot which can parse jobs and draw a diagram of all jobs and which ones are started when.
[13:16] <xnox> start with your startup event (the default one is "startup") and trace it to your jobs, and see what things are blocking what.
[13:16] <adrien_oww> unfortunately, moving away from 0.3.3 is not possible; I know there are some kludges hidden and some of them will break with a newer upstart
[13:17] <xnox> understand.
[13:17] <adrien_oww> I have a fairly good idea of what gets to run after what but that's mostly because there is little parallelization ='( 
[13:17] <xnox> adrien_oww: one should be able to increasing debugging. "--debug" should work, and then collect all logs, which should list all the jobs in order, it should be then easier to analyse where the bottlenecks are.
[13:18] <adrien_oww> I've checked my commits and I don't understand why the service doesn't seem to get started; that said it might be because I'm looking at syslog (started with --verbose on the kernel command-line) and rsyslogd isn't started yet
[13:18] <xnox> check console & dmesg as well.
[13:19] <xnox>  / kmsg
[13:20] <adrien_oww> I'm tempted to be a bit dirty and start on started rsyslogd :D 
[13:21] <adrien_oww> it's almost as soon as I want it too
[13:22] <adrien_oww> otherwise, in dmesg, there isn't much infos
[16:25] <adrien_oww> hmm, had to stop a bit and now getting back on this issue
[16:26] <adrien_oww> I have a script X which "start on started Y"; Y is "start on started rsyslogd" and correctly starts
[16:27] <adrien_oww> but X never starts; Y is an abstract job
[16:28] <adrien_oww> if I check the status, I get "Y (start) starting" and "X (stop) waiting"
[16:28] <adrien_oww> and if I "initctl emit started Y", X is triggered
[16:29] <adrien_oww> the only issue I can think of is that Y is an abstract job but I can't find a confirmation in the doc; however that might only be an issue with older upstart version
[16:29] <adrien_oww> s
[16:41] <adrien_oww> arf, actually Y has a "script" section
[16:55] <xnox> adrien_oww: can you paste full script? if it e.g. has task stanza, started is only emitted once script is completed & exited.
[17:01] <adrien_oww> I think I need to clean things up a bit, both on disk and in my mind
[17:02] <adrien_oww> but if a job is stuck in "starting" then it means it's waiting on something that is "start on starting $it", right?
[17:07] <adrien_oww> ah and upstart 0.3.11, not 0.3.3
[17:19] <xnox> adrien_oww: "A (start) starting", means that "starting A" event was emitted; and "started A" was not.
[17:20] <xnox> adrien_oww: checkout http://upstart.ubuntu.com/cookbook/ it lists all states (reported by status) and which events are emitted when, and which transitions happen when.
[17:20] <xnox> it is a useful reference when things are entangled.
[17:21] <xnox> (cookbook did not exist back in the day....)
[17:25] <adrien_oww> I've checked the cookbook and I can't what could make it never move from "starting" to "started"; the only thing I can think of is that there is one job with "start on starting the-process-that-stays-in-starting-state" and which is not completing
[17:26] <adrien_oww> however the only one like that is redis-server and it does nothing but call the script in /etc/init.d/, the redis-server is wroking and its state is "redis-sever (start) running"