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