[18:19] Woot, an implementation of Cucumber for Erlang. That’ll be useful for me. http://github.com/northscale/cucumberl/blob/master/features/sample.feature http://github.com/northscale/cucumberl/blob/master/src/sample.erl [18:47] Keybuk: suppose I have a job A, and a job B that's start on starting A, and B has post-start exec stop [18:47] post-start exec stop A * [18:47] Keybuk: expected behavior, IMHO, is that B prevents A from starting, and runs instead. [18:48] Keybuk: actual behavior is not, what are your thoughts. [18:52] that a bug was filed about that yesterday [18:53] Keybuk: probably by rstrode notting or plautrba :) [18:54] Keybuk: I'd have filed it but I thought I might've just been doing it wrong. [18:54] * sadmac2 doesn't see it in his launchpad mail [18:56] no, by one of our developers [18:57] Keybuk: hmm. funny we hit that at the same time. [19:00] might be in a slightly different way [19:00] but basically trying to do the same things [19:01] think B ended up killing itself instead of A [19:02] sadmac2: correct,that's what happened AFAICT [19:02] sadmac2: erm [19:02] if you pass --no-wait, it stops itself. if you don't pass --no-wait, it hangs :) [19:04] ah [19:05] that makes sense. Its waiting for itself to stop, which can't happen because it can't progress beyond post-start until its done waiting [19:05] my first thought was that it was ignoring the argument and stopping $UPSTART_JOB instead of the target [19:06] but that all looks right. [19:06] come to think of it, running initctl stop with no arguments will cause some funny things won't it... [19:07] depending on where you do it. [19:07] no. [19:08] Keybuk: whatever terminal you are running is most likely the descendant of some upstart task, so it probably has an UPSTART_JOB of god knows what (most likely the getty or X session, which is actually ok) [19:10] ? [19:10] UPSTART_JOB isn't used if the command has arguments [19:10] Keybuk: right. so if you happen to type "stop" in a terminal with no arguments, the results might be strange. [19:11] sometimes [19:11] in practice, most top-level things are good at sanitising their environment before running things like shells [19:11] good to know. [19:11] PAM does it, for example [19:11] so if you have a PAM session, you have the env cleaned up [19:12] polkit I'd assume the same? [19:14] right [19:56] Keybuk, https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/510130 and https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/510130 [20:09] smoser: that's 2x the same (guess you wanted to point to 2 different bugs) [20:09] oops. [20:10] https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/509841 was the other [21:29] does anyone have an example nginx upstart file? [21:38] anybody have an apache upstart example? [21:41] it seems to me having more examples of typical servers would be a Good Thing [21:42] traviscline: upstart changes api a lot. The result is we don't encourage people to actually /use/ it per se :) [21:42] i just upgraded from 0.3.9 and was using it for apache and varnish [21:42] traviscline: what distro? [21:42] but upped to 0.6.2 so i could use the expect fork / daemon stuff [21:42] ubuntu, 9.10 [21:43] when starting nginx (which daemonizes) with expect daemon the start just hangs [21:43] even though it starts it [21:43] traviscline: doesn't it come with startup scripts? are you building yourself? [21:43] traviscline: try expect fork instead. [21:43] i did, trying again [21:44] start hangs [21:44] with expect fork [21:44] and doesn't start it [21:45] ctl-c'd it -- it thinks the job is running now [21:45] stopping hangs [21:45] traviscline: are you sure this job is running? [21:45] *forking [21:46] ctl-c'd - marked as not running [21:46] when i just run 'nginx' it returns immediately [21:46] and starts at least 2 processes [21:47] running both start and stop with -v produce no additional output [21:48] here's strace output https://gist.github.com/586c7d3aff64c7e46429 [21:49] traviscline: no clone call [21:49] that does mark the job as running though [21:50] sadmac2: sorry, not familiar [21:50] is that nginx's fault? [21:50] traviscline: the strace doesn't show anything forking. at all. [21:51] sadmac2: https://gist.github.com/586c7d3aff64c7e46429 that's it when i don't run it with start [21:51] this is my job https://gist.github.com/084de4d8d90ab87d6cc9 [21:52] traviscline: there's no use stracing the start command. [21:52] ok [21:52] any input on debugging paths? [21:52] or should i punt because upstart isn't ready for real use? [21:53] traviscline: try strace -f [21:54] output looks appoximately the same [21:54] approximately* [21:54] ...that's not right... [21:54] that makes no sense in fact [21:54] it should tell you what both sides of the fork do [21:55] sadmac2: with -f https://gist.github.com/586c7d3aff64c7e46429 [21:55] traviscline: no start [21:55] or did you want that on vanilla nginx (not start) [21:55] gotcha [21:56] traviscline: stracing start makes no sense. It'll just tell us what the start command is doing. It tells us nothing about nginx [21:56] sadmac2: i see, sorry. https://gist.github.com/586c7d3aff64c7e46429 there it is with -f [21:59] expect fork should do it. [21:59] something odd happens to the first fork though [22:00] Keybuk: any idea what's up with 6396 in that strace? [22:06] might be the same as this https://bugs.launchpad.net/upstart/+bug/406397 [22:06] anyhow, it looks like there isn't an easy fix and i'll just use supervised to keep services up [22:06] or something like it [22:31] sadmac2: probably getting stuck with fork following [22:31] either by SIGCHLD handler, or because the job does something weird [22:31] like fork/exec something else first [22:47] Keybuk: figured that much. It is weird in that we end up with two daemon processes, but with expect fork I'd think we'd be done tracing before that stuff happened === Keybuk changed the topic of #upstart to: Upstart 0.6.5 "Our last, best hope for victory" | http://upstart.ubuntu.com/