xnox | SegFaultAX: can you file a bug against upstart with example process that does that? | 02:21 |
---|---|---|
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:04 |
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:49 |
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:50 |
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:51 |
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:52 |
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 | 11:55 |
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:52 |
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 | 12:53 |
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:15 |
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:16 |
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:17 |
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:18 |
xnox | / kmsg | 13:19 |
adrien_oww | I'm tempted to be a bit dirty and start on started rsyslogd :D | 13:20 |
adrien_oww | it's almost as soon as I want it too | 13:21 |
adrien_oww | otherwise, in dmesg, there isn't much infos | 13:22 |
adrien_oww | hmm, had to stop a bit and now getting back on this issue | 16:25 |
adrien_oww | I have a script X which "start on started Y"; Y is "start on started rsyslogd" and correctly starts | 16:26 |
adrien_oww | but X never starts; Y is an abstract job | 16:27 |
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:28 |
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:29 |
adrien_oww | arf, actually Y has a "script" section | 16:41 |
xnox | adrien_oww: can you paste full script? if it e.g. has task stanza, started is only emitted once script is completed & exited. | 16:55 |
adrien_oww | I think I need to clean things up a bit, both on disk and in my mind | 17:01 |
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:02 |
adrien_oww | ah and upstart 0.3.11, not 0.3.3 | 17:07 |
xnox | adrien_oww: "A (start) starting", means that "starting A" event was emitted; and "started A" was not. | 17:19 |
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:20 |
xnox | (cookbook did not exist back in the day....) | 17:21 |
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:25 |
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" | 17:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!