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