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