[01:27] <RyanPrior> How can I use upstart to control things like apache? Right now I'm using invoke-rc.d but upstart seems like the direction Ubuntu is moving in.
[15:41]  * rgl waves
[15:42] <rgl> what is the best way to disable the tty?  edit  /etc/default/console-setup, remove /etc/event.d/tty*, anything else?
[15:42] <Keybuk> that would work
[15:44] <rgl> but what is *the way*? :D
[15:45] <Keybuk> there isn't one yet
[15:45] <Keybuk> you could edit it and comment out the "start on" line
[15:45] <rgl> if I remove the tty* files, will htye be recreted after package update?
[15:47] <Keybuk> no
[15:47] <Keybuk> (assuming dpkg)
[15:49] <rgl> ah;  so I'll remove them.  thx :)
[15:56] <sadmac2> Keybuk: did you see my email?
[15:57] <Keybuk> sadmac2: err?
[15:57] <sadmac2> Keybuk: I sent you an email
[15:58] <sadmac2> Keybuk: did it not make it?
[15:58] <Keybuk> what was the subject?
[15:58] <sadmac2> Keybuk: "States as Flags"
[15:59] <Keybuk> oh, yes, I have that one
[15:59] <Keybuk> haven't read it yet
[16:00] <sadmac2> ah.
[16:08] <wasabi> Keybuk: congrats on the awesomeness. good to see the stuff we talked about finally seeing the light of day
[16:20] <Keybuk> wasabi: yeah, is good :p
[16:22] <wasabi> i like how you refined the instance/job stuff.
[16:22] <Keybuk> that stuff is working rather well now
[16:23] <wasabi> i love it when ideas like that come together, and you know, if you look hard enough, it can be elegant... and then it is
[16:23] <Keybuk> there's still a few bits that aren't quite perfect yet
[16:25] <Keybuk> but I'm hoping they'll clean themselves up over time
[16:26] <wasabi> im still curious about some of the problems we had with figuring out how to properly track large event sequences
[16:27] <Keybuk> how do you mean?
[16:28] <wasabi> oh, like, something that only should be active between the time the network interface is up and when it is about to go down.
[16:28] <Keybuk> that bit's easy, no?
[16:28] <Keybuk>   from interface-up
[16:28] <Keybuk>   until interface-down $IFACE
[16:28] <wasabi> it's easy, except for when the 'it is up' state can be forgotten, for instance, by manually restarting the event.
[16:28] <Keybuk> ahh
[16:28] <Keybuk> yeah, the whole forgotten thing
[16:28] <wasabi> since it's a state machine that is independent from the system itself.
[16:29] <wasabi> I have a hunch that it's going to lead to problems... but I'm not sure.
[16:29] <Keybuk> me neither
[16:30] <Keybuk> I guess whatever knows the network is up or down knows
[16:30] <Keybuk> or maybe that doesn't either
[16:30] <wasabi> So like, you have apache running, it is network-up to network-down.... network-up happens, so apache starts.... but eh user manually restarts apache. state machine is cleared.... now when the network goes down, apache doesn't.
[16:31] <wasabi> unless the up/down part are independent.
[16:31] <wasabi> which makes the whole state part not very useful or interesting.
[16:31] <Keybuk> they're independant
[16:31] <wasabi> from interface-up until interface-down    ?      that can trigger stop on interface-down without ever triggering interface-up before?
[16:31] <Keybuk> a more interesting question is, if the sysadmin manually started apache, _should_ it be automatically stopped?
[16:32] <Keybuk> at the moment, yeah
[16:32] <wasabi> Yeah. I dunno. I think that in the specific case of apache relying on the network, yeah....
[16:33] <Keybuk> states is a definite 0.5.x problem
[16:34] <sadmac2> Keybuk: the email I sent is pertinent to this
[16:34] <sadmac2> to states rather
[16:35] <Keybuk> indeed
[16:35] <sadmac2> and now its lunch time
[16:35]  * sadmac2 goes for food
[16:37] <Keybuk> wasabi: I'm pretty sure Upstart is almost as good a service and task manager as it can be now
[16:37] <Keybuk> which was my goal for 0.5
[16:37] <wasabi> Yeah. I think so too.
[16:37] <Keybuk> the next job is to make sure we have the events/states/etc. stuff right
[16:38] <Keybuk> the only bit I'm not 100% happy with is the blocking of commands
[16:38] <Keybuk> it's not _quite_ right
[16:38] <Keybuk> and it's because there's a wimp out
[16:38] <Keybuk> when you do "start apache HTTPS=true", the HTTPS is not immediately stored in the job environment
[16:38] <Keybuk> instead it's in the "next environment" which isn't copied over until the job is actually starting
[16:39] <Keybuk> that way, if you do "stop --no-wait apache && start apache HTTPS=true" to restart with SSL enabled
[16:39] <Keybuk> the pre-stop and post-stop scripts are run _without_ that variable
[16:39] <Keybuk> so stop scripts always match start scripts
[16:39] <Keybuk> _but_ there's only one blocking command
[16:39] <Keybuk> so if you stop while starting, the start immediately cancels
[16:39] <Keybuk> and I'm not happy with that
[16:40] <Keybuk> if the blocking command was queued, that would feel right I think
[16:40] <Keybuk> but need to think about it
[16:40] <Keybuk> certainly, if the blocking command was queued, "watershed" jobs would be trivial to implement :p
[16:40] <Keybuk> nih_list_add (job->next_blocking, &request->entry);
[16:40] <Keybuk> job->restart = TRUE;
[16:40] <Keybuk> :p
[16:43] <wasabi> where's uds at this next time?
[16:43] <wasabi> as part of my employeement contract i got the owner here to send me to two conferences a year, related or unrelated to what I do at work. =)
[16:44] <Keybuk> Prague
[16:44] <wasabi> Oooh.
[16:44] <Keybuk> in three weeks
[16:44] <wasabi> Oh. Darn.
[16:44] <Keybuk> after that it's SF in the first week of December
[16:45] <wasabi> Man, Prague would be awesome.
[16:45] <wasabi> Hope ya'll have fun.
[16:46] <Keybuk> I expect to be busy :(
[16:47] <Keybuk> going to try and skate around the city though
[20:41] <Keybuk> what should the D-Bus object path of the only instance of a non-instance job be?
[21:54] <wasabi> what is it for an instance?
[21:54] <Keybuk> the name of the instance
[21:54] <wasabi> job/instance  ?
[21:54] <wasabi> job
[21:54] <Keybuk> /com/ubuntu/Upstart/jobs/getty/tty1
[21:54] <Keybuk> for example
[21:54] <wasabi> oh. Just leave off the last part of the path
[21:54] <Keybuk> that's the job though
[21:55] <wasabi> Oh. Hah.
[21:55] <wasabi> "default" =)
[21:55] <ion_> "instance"
[21:55] <ion_> "amigarules"
[21:55] <wasabi> i would make up a special name for it, so it's namespace is equiv to instances themselves.
[21:56] <Keybuk> yeah, some special name
[21:56] <wasabi> makes enumeration and stuff easier
[21:56]  * Keybuk is having a very strange valgrind issue at the moment
[22:00] <Keybuk> it's complaining about reachable data
[22:01] <Keybuk> which doesn't make sense given the context
[22:01] <Keybuk> the pointer is reachable by a *far* bigger block it's not complaining about
[22:26] <Keybuk> \o/
[22:26] <Keybuk> http://bioshock.netsplit.com/~scott/yay-dbus.png
[22:29] <ion_> :-)
[22:45] <ion_> Did you manage to resolve the valgrind issue?
[22:48] <ion_> keybuk: Hilight
[22:51] <Keybuk> ion_: no
[22:51] <Keybuk> I just suppressed it
[22:52] <Keybuk> it errors that the dbus path is still reachable
[22:52] <Keybuk> (ie. not freed)
[22:52] <Keybuk> but it's reachable by an even bigger object that's not freed
[22:52] <Keybuk> which is reachable by the hash table of objects that aren't freed
[22:52] <Keybuk> so I don't quite see why it's complaining about the bit at the bottom of the stack
[22:53] <ion_> Heh
[22:53] <ion_> It's understandable ‒ it's not as if computers are deterministic machines. :-)
[22:54] <Keybuk> if I change the "complicated" function call with nih_sprintf
[22:54] <Keybuk> it's fine
[22:54] <Keybuk> the only different that I can tell is that one uses malloc() and the other realloc()
[23:51] <wasabi> So... does upstart have aspirations to be in other distros? Or is that a concern you don't care to think about?
[23:51] <wasabi> Oh, guess it doesn't matter. We have com.redhat crap in there too