[01:13] I want to use upstart for mochiweb - an erlang web server [01:14] the server knows how to kill itself so usualy people use a script that tells erlang to stop the server and the erlang VM [01:14] in upstart the stop event kill the process so aren't they both doing the same thing? === ion__ is now known as ion [08:48] hello [08:50] I'm playing with upstart and would like to run a script before runlevel [016]. I tried several ways to express what I want but "start on starting runlevel [016]" seems to be right but my job doesn't start. I've tested the script before with initctl emit test and that was fine. any ideas? [08:51] note: the script should shutdown any running kvm guest with virsh shutdown. [12:33] what does this means 'stop on runlevel [!023456]' [12:34] I'm trying to understand when I should stop my server. It's a web server [12:37] Effectively ‘stop on runlevel 1’, as long as [0123456] are the only runlevel event parameters. ‘start on filesystem’, ‘stop on runlevel [06]’ might be appropriate for Ubuntu 9.10. [12:39] ion: hi, you helped me yesterday. for a mochiweb app, when do I need to stop it? do I need the [!023456] or something else? [12:40] ‘start on filesystem and net-device-up’ instead of ‘start on filesystem’ might be appropriate for a network service. [12:40] ‘stop on runlevel [06]’ probably works. === pocek_ is now known as pocek [12:41] what about 'start on startup' and 'stop on shutdown' ? [12:41] ok. I want to be sure that the network is up [12:41] thanks [12:42] ‘start on stopped rc RUNLEVEL=[2345]’ to start after the entire rc2 has been run. [12:42] do I need to wait for the entire rc2? [12:43] Depends. You might not even need to wait for a network device, if the service listens on all present and future interfaces. I don’t remember what mochiweb does by default. [12:46] I don't mind waiting. startup speed is not very important as long as it's reliable. it just help me understand how stuff work [12:49] We probably should have networking emit an event when *all* interfaces defined in /e/n/i are up. That would be reliable. In fact, waiting for the entire rc2 to finish doesn’t really guarantee all network devices are up. They just probably are. :-) ‘start on net-device-up’ only guarantees one interface is up. Currently one could do ‘start on filesystem and net-device-up ethfoo and net-device-up ethbar’ to make sure ethfoo and ethbar are up. [12:53] are you missing couple of and in the last example? [12:53] Nope [12:53] what do I need to replace ethfoo and ethbar with? [12:54] all I want is to start a web server reliably :) couldn't find nginx or apache examples [12:54] The names of the network interfaces (‘auto ethfoo’ entries in /etc/network/interfaces) [12:55] it should be protable. I want to use the same job on my dev machine and on vps hosting [13:25] ion: I've created a job for my mochiweb app but the status is stop/waiting [13:25] http://dpaste.com/122823/ [14:08] ion: any idea? === ev1 is now known as ev [16:20] benc: Add ‘exec >/tmp/log 2>&1’ just after the ‘script’ line, start the job and look at the log. [16:33] Keybuk: I've had some thoughts on respawn [16:33] and limits thereof [16:39] For each job, have an integer respawn_delay initialized to 1. Whenever the job dies, respawn_delay *= 2; respawn_delay -= number_of_seconds_the_job_was_running_before_it_died * 1; respawn_delay = clip (respawn_delay, 1, 300); respawn_after (respawn_delay); // TODO tune the constants [16:39] ion: something quite like that, yes. [19:42] Keybuk: new bug filed. You're welcome [19:42] :) [19:45] huh? [19:46] sadmac: no it doesn't [19:47] Keybuk: it doesn't? [19:47] not here [19:48] Keybuk: ...oops. I accidentally 0.3 [19:48] huh? [19:49] Keybuk: its a 0.3 bug [19:49] why? [19:49] 0.6 is no different in this regard [19:49] Keybuk: apparently it is. over here init has 3 persistant connections to /dev/console [19:50] yes, stdin, stdout, stderr [19:50] wing-commander scott% sudo ls -l /proc/1/fd [19:50] total 0 [19:50] lrwx------ 1 root root 64 2009-11-20 13:50 0 -> /dev/console [19:50] lrwx------ 1 root root 64 2009-11-20 13:50 1 -> /dev/console [19:50] lrwx------ 1 root root 64 2009-11-20 13:50 2 -> /dev/console [19:50] Keybuk: oh, so it does have the /dev/console, but the SAK key doesn't kill it for you? [19:50] Keybuk: yeah, that's because X is on tty1 here [19:51] X is on tty7 [19:51] (here) [19:51] that seems to be the killer [19:52] so you're probably killing X, not init [19:52] Keybuk: killing X is desirable [19:52] Keybuk: its also killing init [19:53] I can't see anything that indicates why it would [19:53] for a start, SAK only applies to a TTY [19:54] what do you mean? [19:57] SAK is handled in the TTY code [19:57] /dev/console is not a tty [19:58] Keybuk: init and X are on the same tty for us [19:59] err [19:59] init isn't on a TTY [19:59] Keybuk: it has open FDs to the active tty [20:00] sadmac: but if it's /dev/console, then it theoretically would kill it on whatever tty you did SAK on [20:00] not just tty1 [20:00] exactly [20:01] but since /dev/console is separate to the tty later [20:01] layer [20:01] (it's not /dev/tty0) [20:01] it won't [20:01] Keybuk: not what the kernel docs say [20:02] which docs? [20:02] Keybuk: Documentation/SAK.txt [20:02] Keybuk: "On the PC keyboard, SAK kills all applications which have /dev/console opened." [20:03] see the first line [20:03] Linux 2.4.2 Secure Attention Key (SAK) handling [20:03] ~~~~~ [20:03] there is that, isn't there... [20:03] the sysrq.txt docs say "given console" [20:04] besides [20:04] sysvinit holds /dev/console open too [20:05] (afaik) [20:12] Keybuk: its by SID from the foreground console [20:12] and nothing on fedora has SID 1 but init [20:13] SID? [20:13] Keybuk: session id [20:13] Keybuk: the code is 1) get foreground tty. 2) get tty->session 3) kill processes with that session ID [20:14] so why doesn't it kill init on other ttys? [20:14] ah! [20:14] because getty will take the session [20:15] Keybuk: I dunno if we should call that an upstart bug. Its kind of a sloppy mess [20:16] Keybuk: in an abstract sense, tty1 should have X's session ID. [20:21] yes [20:21] it should [20:21] in fact, X will sulk heavily (ie. crash) if something else takes it [20:21] but tty1 is in KD_GRAPHICS mode [20:21] so all bets are off [20:22] Keybuk: will TIOCSCTTY fail in graphics mode? [20:22] no idea [20:22] might be worth a shot [20:22] notting: thoughts on all this? [20:23] (on a conf call, not reading yet) [20:24] Keybuk: If upstart does close stdin/out/err, that would get it as well, would it not? [20:25] "get it" ? [20:26] Keybuk: kill the bug [20:27] I don't know what the session would become in that case, but you can't be the controller for a terminal that you don't have open, can you? [20:28] no idea [20:28] Keybuk: I thought you were the font of obscure tty behavior :) [20:28] time to go screw around with it. /me waits for $dayjob to end/ [20:54] Keybuk, you guys doing dinner anywhere tonight? I'd love to meet up with ya. [20:56] there's the BBQ and AllStars event at the hotel [20:57] hmm [20:57] i haven't been by at all. been swamped at Real Job [21:07] sadmac: hey, that bug has a dup [21:15] notting: really? [21:15] yeah, someone filed a bug against X about it [21:43] hm [22:00] if I need to export HOME, do I do this at the top of the job or inside the script/end script ?