[05:03] <sadmac> Keybuk: are you here?
[09:10] <Keybuk> sadmac: hi
[11:29] <Keybuk> ion_: did you get a chance to read through http://upstart.ubuntu.com/wiki/JobAtomicity ?
[11:34] <ion_> Thanks for pointing it out, will read.
[15:36] <sadmac_> Keybuk: initctl start isn't behaving like it should
[15:40] <sadmac_> It blocks until the job is stopped again, rather than until its started.
[15:41] <Keybuk> did you declare the job as a service?
[15:41] <sadmac_> Keybuk: ...I'm guessing not. What's needed to do that?
[15:42] <Keybuk> "service"
[15:42] <Keybuk> or "respawn"
[15:42] <sadmac_> ahh.
[15:44] <Keybuk> there's some debate there about which is the right default
[15:49]  * sadmac_ needs a kvm with network support
[15:49] <sadmac_> hard to test upstart through ssh
[16:10] <Keybuk> heh
[16:18] <sadmac_> Keybuk: if a pre-start script returns nonzero, does the job not run?
[16:19] <Keybuk> right
[16:19] <Keybuk> the job will fail
[16:19] <sadmac_> perfect
[16:20] <Keybuk> all scripts are run with -e too
[16:22] <sadmac_> ahh, that explains some things I saw earlier
[16:22]  * Keybuk believes in properly written shell scripts ;)
[16:23] <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:24] <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
[17:48] <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:53] <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:54] <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:55] <Keybuk> in addition to what all the other processes get
[17:55] <Keybuk> post-stop doesn't have those variables
[17:55] <ion_> Alright
[18:05] <ion_> keybuk: Wouldn’t it be better for multiple concurrent stop requests all blocked?
[18:06] <ion_> keybuk: And also if concurrent start requests all blocked until it’s running or it fails?
[20:11] <Keybuk> I'm not sure
[20:12] <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:13] <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:14] <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:15] <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:16] <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:18] <ion_> Aye
[20:21] <sadmac> Keybuk: ...I did evil
[20:21] <sadmac> Keybuk: http://sadmac.fedorapeople.org/rhgb
[20:21] <sadmac> put the tea down
[20:22] <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:23] <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:26] <sadmac> busy-waiting is scary.
[20:29] <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:30] <sadmac> ion_: thinking about that. Is there a shell exposure of the necessary forms of inotify?
[20:31] <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:32] <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:35] <ion_> I don’t know how they handle [ -e /foo ] || someinotifyprogram /foo when /foo appears after [ ] but before someinotifyprogram.
[21:20] <sadmac> ion_: I have it inotify based now :)
[21:21] <sadmac> I'll see what the others concerned think
[21:22] <ion_> What did you use?
[21:44] <sadmac> ion_: inotifywait -m /dev/pts 2> /dev/null | grep -m 1 "CREATE" > /dev/null
[21:45] <ion_> How about if /dev/pts/0 gets created before inotifywait is run?
[21:47] <sadmac> ion_: its in an if [ -e ] block
[21:47] <ion_> There’s still a race condition. :-)
[21:48] <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:52] <ion_> Better start watching the directory first, then check for the file’s existence, and continue watching if the file doesn’t exist.
[22:54] <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