| 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. | 01:27 |
|---|---|---|
| === suihkulo1ki is now known as suihkulokki | ||
| * rgl waves | 15:41 | |
| 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:42 |
| rgl | but what is *the way*? :D | 15:44 |
| 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:45 |
| Keybuk | no | 15:47 |
| Keybuk | (assuming dpkg) | 15:47 |
| rgl | ah; so I'll remove them. thx :) | 15:49 |
| sadmac2 | Keybuk: did you see my email? | 15:56 |
| Keybuk | sadmac2: err? | 15:57 |
| sadmac2 | Keybuk: I sent you an email | 15:57 |
| sadmac2 | Keybuk: did it not make it? | 15:58 |
| Keybuk | what was the subject? | 15:58 |
| sadmac2 | Keybuk: "States as Flags" | 15:58 |
| Keybuk | oh, yes, I have that one | 15:59 |
| Keybuk | haven't read it yet | 15:59 |
| sadmac2 | ah. | 16:00 |
| wasabi | Keybuk: congrats on the awesomeness. good to see the stuff we talked about finally seeing the light of day | 16:08 |
| Keybuk | wasabi: yeah, is good :p | 16:20 |
| wasabi | i like how you refined the instance/job stuff. | 16:22 |
| Keybuk | that stuff is working rather well now | 16:22 |
| 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:23 |
| Keybuk | but I'm hoping they'll clean themselves up over time | 16:25 |
| wasabi | im still curious about some of the problems we had with figuring out how to properly track large event sequences | 16:26 |
| Keybuk | how do you mean? | 16:27 |
| 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:28 |
| wasabi | I have a hunch that it's going to lead to problems... but I'm not sure. | 16:29 |
| Keybuk | me neither | 16:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| Keybuk | states is a definite 0.5.x problem | 16:33 |
| sadmac2 | Keybuk: the email I sent is pertinent to this | 16:34 |
| sadmac2 | to states rather | 16:34 |
| Keybuk | indeed | 16:35 |
| sadmac2 | and now its lunch time | 16:35 |
| * sadmac2 goes for food | 16:35 | |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:43 |
| 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:44 |
| wasabi | Man, Prague would be awesome. | 16:45 |
| wasabi | Hope ya'll have fun. | 16:45 |
| Keybuk | I expect to be busy :( | 16:46 |
| Keybuk | going to try and skate around the city though | 16:47 |
| === keesj is now known as azerty | ||
| === Amaranth_ is now known as Amaranth | ||
| === azerty is now known as keesj | ||
| Keybuk | what should the D-Bus object path of the only instance of a non-instance job be? | 20:41 |
| 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:54 |
| 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:55 |
| 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 | 21:56 | |
| Keybuk | it's complaining about reachable data | 22:00 |
| 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:01 |
| Keybuk | \o/ | 22:26 |
| Keybuk | http://bioshock.netsplit.com/~scott/yay-dbus.png | 22:26 |
| ion_ | :-) | 22:29 |
| ion_ | Did you manage to resolve the valgrind issue? | 22:45 |
| ion_ | keybuk: Hilight | 22:48 |
| Keybuk | ion_: no | 22:51 |
| Keybuk | I just suppressed it | 22:51 |
| 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:52 |
| ion_ | Heh | 22:53 |
| ion_ | It's understandable ‒ it's not as if computers are deterministic machines. :-) | 22:53 |
| 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() | 22:54 |
| 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 | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
