| benc | I want to use upstart for mochiweb - an erlang web server | 01:13 |
|---|---|---|
| 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? | 01:14 |
| === ion__ is now known as ion | ||
| babel | hello | 08:48 |
| 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:50 |
| babel | note: the script should shutdown any running kvm guest with virsh shutdown. | 08:51 |
| benc | what does this means 'stop on runlevel [!023456]' | 12:33 |
| benc | I'm trying to understand when I should stop my server. It's a web server | 12:34 |
| 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:37 |
| 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:39 |
| 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:40 |
| === pocek_ is now known as pocek | ||
| 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:41 |
| 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:42 |
| 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:43 |
| 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:46 |
| 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:49 |
| 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:53 |
| 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:54 |
| benc | it should be protable. I want to use the same job on my dev machine and on vps hosting | 12:55 |
| benc | ion: I've created a job for my mochiweb app but the status is stop/waiting | 13:25 |
| benc | http://dpaste.com/122823/ | 13:25 |
| benc1 | ion: any idea? | 14:08 |
| === ev1 is now known as ev | ||
| ion | benc: Add ‘exec >/tmp/log 2>&1’ just after the ‘script’ line, start the job and look at the log. | 16:20 |
| sadmac | Keybuk: I've had some thoughts on respawn | 16:33 |
| sadmac | and limits thereof | 16:33 |
| 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. | 16:39 |
| sadmac | Keybuk: new bug filed. You're welcome | 19:42 |
| sadmac | :) | 19:42 |
| Keybuk | huh? | 19:45 |
| Keybuk | sadmac: no it doesn't | 19:46 |
| sadmac | Keybuk: it doesn't? | 19:47 |
| Keybuk | not here | 19:47 |
| sadmac | Keybuk: ...oops. I accidentally 0.3 | 19:48 |
| Keybuk | huh? | 19:48 |
| 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:49 |
| 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:50 |
| Keybuk | X is on tty7 | 19:51 |
| Keybuk | (here) | 19:51 |
| sadmac | that seems to be the killer | 19:51 |
| 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:52 |
| Keybuk | I can't see anything that indicates why it would | 19:53 |
| Keybuk | for a start, SAK only applies to a TTY | 19:53 |
| sadmac | what do you mean? | 19:54 |
| Keybuk | SAK is handled in the TTY code | 19:57 |
| Keybuk | /dev/console is not a tty | 19:57 |
| sadmac | Keybuk: init and X are on the same tty for us | 19:58 |
| Keybuk | err | 19:59 |
| Keybuk | init isn't on a TTY | 19:59 |
| sadmac | Keybuk: it has open FDs to the active tty | 19:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| Keybuk | besides | 20:04 |
| Keybuk | sysvinit holds /dev/console open too | 20:04 |
| Keybuk | (afaik) | 20:05 |
| sadmac | Keybuk: its by SID from the foreground console | 20:12 |
| sadmac | and nothing on fedora has SID 1 but init | 20:12 |
| 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:13 |
| 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:14 |
| sadmac | Keybuk: I dunno if we should call that an upstart bug. Its kind of a sloppy mess | 20:15 |
| sadmac | Keybuk: in an abstract sense, tty1 should have X's session ID. | 20:16 |
| 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:21 |
| 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:22 |
| notting | (on a conf call, not reading yet) | 20:23 |
| sadmac | Keybuk: If upstart does close stdin/out/err, that would get it as well, would it not? | 20:24 |
| Keybuk | "get it" ? | 20:25 |
| sadmac | Keybuk: kill the bug | 20:26 |
| 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:27 |
| 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:28 |
| wasabi | Keybuk, you guys doing dinner anywhere tonight? I'd love to meet up with ya. | 20:54 |
| Keybuk | there's the BBQ and AllStars event at the hotel | 20:56 |
| wasabi | hmm | 20:57 |
| wasabi | i haven't been by at all. been swamped at Real Job | 20:57 |
| notting | sadmac: hey, that bug has a dup | 21:07 |
| sadmac_home | notting: really? | 21:15 |
| notting | yeah, someone filed a bug against X about it | 21:15 |
| sadmac_home | hm | 21:43 |
| benc2 | if I need to export HOME, do I do this at the top of the job or inside the script/end script ? | 22:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!