| sadmac | Keybuk: are you here? | 05:03 |
|---|---|---|
| Keybuk | sadmac: hi | 09:10 |
| Keybuk | ion_: did you get a chance to read through http://upstart.ubuntu.com/wiki/JobAtomicity ? | 11:29 |
| ion_ | Thanks for pointing it out, will read. | 11:34 |
| sadmac_ | Keybuk: initctl start isn't behaving like it should | 15:36 |
| sadmac_ | It blocks until the job is stopped again, rather than until its started. | 15:40 |
| Keybuk | did you declare the job as a service? | 15:41 |
| sadmac_ | Keybuk: ...I'm guessing not. What's needed to do that? | 15:41 |
| Keybuk | "service" | 15:42 |
| Keybuk | or "respawn" | 15:42 |
| sadmac_ | ahh. | 15:42 |
| Keybuk | there's some debate there about which is the right default | 15:44 |
| * sadmac_ needs a kvm with network support | 15:49 | |
| sadmac_ | hard to test upstart through ssh | 15:49 |
| Keybuk | heh | 16:10 |
| sadmac_ | Keybuk: if a pre-start script returns nonzero, does the job not run? | 16:18 |
| Keybuk | right | 16:19 |
| Keybuk | the job will fail | 16:19 |
| sadmac_ | perfect | 16:19 |
| Keybuk | all scripts are run with -e too | 16:20 |
| sadmac_ | ahh, that explains some things I saw earlier | 16:22 |
| * Keybuk believes in properly written shell scripts ;) | 16:22 | |
| ion_ | -e ftw. | 16:23 |
| sadmac_ | It gets interesting when you're trying to debug stuff, and your ls's and tty's are failing and bringing everything to a halt | 16:23 |
| Keybuk | heh | 16:24 |
| sadmac_ | But now rhgb should work :D | 16:24 |
| ion_ | You can always say set +e temporarily. | 16:24 |
| sadmac_ | It makes me all tingly | 16:24 |
| === elmarco is now known as elmarco|bzz | ||
| ion_ | “Extra handling is required in both the pre-start and post-stop scripts depending on this variable” | 17:48 |
| ion_ | keybuk: post-stop? | 17:48 |
| Keybuk | ion_: ref? | 17:53 |
| ion_ | keybuk: The http://upstart.ubuntu.com/wiki/JobAtomicity page you mentioned. :-) | 17:53 |
| Keybuk | ion_: that's correct | 17:53 |
| Keybuk | ie. start apache HTTPS=yes | 17:53 |
| Keybuk | HTTPS=yes should be set in post-stop | 17:53 |
| Keybuk | since it might have to undo things done in pre-start | 17:53 |
| ion_ | keybuk: Does that conflict with what we talked about earlier, or am i missing something? | 17:53 |
| Keybuk | no | 17:54 |
| Keybuk | what we talked about earlier was something like | 17:54 |
| Keybuk | stop on wibble | 17:54 |
| Keybuk | initctl emit wibble WIBBLED=YES | 17:54 |
| Keybuk | the pre-stop script will have two extra environment variables | 17:54 |
| Keybuk | WIBBLED=YES | 17:54 |
| Keybuk | UPSTART_STOP_EVENTS=wibble | 17:54 |
| Keybuk | in addition to what all the other processes get | 17:55 |
| Keybuk | post-stop doesn't have those variables | 17:55 |
| ion_ | Alright | 17:55 |
| ion_ | keybuk: Wouldn’t it be better for multiple concurrent stop requests all blocked? | 18:05 |
| ion_ | keybuk: And also if concurrent start requests all blocked until it’s running or it fails? | 18:06 |
| Keybuk | I'm not sure | 20:11 |
| Keybuk | what would be the benefit of multiple stop/start requests all blocking | 20:12 |
| Keybuk | [1] start apache HTTPS=yes | 20:12 |
| Keybuk | [2] stop apache | 20:12 |
| Keybuk | [3] start apache HTTPS=no | 20:12 |
| Keybuk | surely #1 should be cancelled and unblocked by #2 | 20:12 |
| ion_ | Yes | 20:12 |
| Keybuk | it shouldn't subsequently reblock because #3 happens | 20:12 |
| ion_ | [1] start apache HTTPS=yes | 20:13 |
| ion_ | [2] start apache HTTPS=no | 20:13 |
| Keybuk | #2 will fail because it's already started | 20:13 |
| ion_ | apache should start with HTTPS=yes, but both should block IMHO. | 20:13 |
| ion_ | Oh | 20:13 |
| Keybuk | it has to fail, because even if it said "ok, and I'll block" it's lying to you | 20:13 |
| ion_ | That’s okay, too. | 20:13 |
| Keybuk | (since it doesn't result in an apache with no http) | 20:13 |
| Keybuk | start will fail if the goal is already | 20:14 |
| Keybuk | +start | 20:14 |
| Keybuk | stop will fail if the goal is already stop | 20:14 |
| ion_ | Yeah, i’m fine with that. | 20:14 |
| Keybuk | it used to be that in the 1/2/3 example above, #1 would actually block until apache stopped again | 20:14 |
| Keybuk | and #2 would block for the same length of time | 20:14 |
| Keybuk | that seemed wrong to me | 20:15 |
| Keybuk | if it's not going to start, it should unblock immediately and return an error code | 20:15 |
| ion_ | Right | 20:16 |
| Keybuk | likewise the "stop apache" should unblock and return an error code when someone on another console tries to start apache again | 20:16 |
| ion_ | Aye | 20:18 |
| sadmac | Keybuk: ...I did evil | 20:21 |
| === Amaranth_ is now known as Amaranth | ||
| sadmac | Keybuk: http://sadmac.fedorapeople.org/rhgb | 20:21 |
| sadmac | put the tea down | 20:21 |
| Keybuk | heh | 20:22 |
| Keybuk | doesn't seem bad to me | 20:22 |
| Keybuk | I like the pre-start exec test -x thing :) | 20:22 |
| Keybuk | you know that post-start will be run*after* rhgb --no-daemon right? | 20:22 |
| Keybuk | ah, no, you appear to be deliberately waiting for the pts it creates | 20:22 |
| Keybuk | so that's right | 20:22 |
| Keybuk | pop-tty should probably be in the pre-stop script | 20:23 |
| Keybuk | otherwise the pty will be gone while rhgb isn't | 20:23 |
| Keybuk | but hmm, pre-stop isn't run when it dies | 20:23 |
| Keybuk | so yeah, post-stop it'll have to be | 20:23 |
| sadmac | busy-waiting is scary. | 20:26 |
| sadmac | Keybuk: we could reeeely improve the elegance of all this if we could ship a working logd | 20:29 |
| ion_ | Perhaps write a small script that uses inotify to wait for the file. | 20:29 |
| sadmac | ion_: thinking about that. Is there a shell exposure of the necessary forms of inotify? | 20:30 |
| ion_ | Uh, i meant program, as in a C program, unless something equivalent already exists. | 20:31 |
| sadmac | ion_: ahh. yeah, I might. | 20:31 |
| ion_ | There seem to be tools using inotify. | 20:31 |
| ion_ | inotify-tools - command-line programs providing a simple interface to inotify | 20:32 |
| ion_ | iwatch - realtime filesystem monitoring program using inotify | 20:32 |
| ion_ | iwatch seems to depend on Perl. | 20:32 |
| ion_ | I don’t know how they handle [ -e /foo ] || someinotifyprogram /foo when /foo appears after [ ] but before someinotifyprogram. | 20:35 |
| sadmac | ion_: I have it inotify based now :) | 21:20 |
| sadmac | I'll see what the others concerned think | 21:21 |
| ion_ | What did you use? | 21:22 |
| sadmac | ion_: inotifywait -m /dev/pts 2> /dev/null | grep -m 1 "CREATE" > /dev/null | 21:44 |
| ion_ | How about if /dev/pts/0 gets created before inotifywait is run? | 21:45 |
| sadmac | ion_: its in an if [ -e ] block | 21:47 |
| ion_ | There’s still a race condition. :-) | 21:47 |
| sadmac | a very small one | 21:48 |
| ion_ | Aren’t they all? ;-) | 21:48 |
| sadmac | and as long as this damn thing takes to start I'm not worried. | 21:48 |
| ion_ | Better start watching the directory first, then check for the file’s existence, and continue watching if the file doesn’t exist. | 21:52 |
| Keybuk | sadmac: logd strikes me as a bit of a hack | 22:54 |
| Keybuk | it shouldn't exist, instead one of the other logging daemons should be patched | 22:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!