[01:28] hello! I'm running Gutsy and unable to get a text mode login with Ctrl-Alt-F[1..6]. Help! [12:30] heh @ Absorto [12:30] that's actually the most logical bug to blame on Upstart in a while [12:30] better than last week when someone filed a bug on Upstart for muting their sound card when they switched to a VT [12:30] haha [12:30] He even had a whopping five minutes of patience! [12:32] (I *love* the fact that sound card stops when you switch VT [12:32] it proves that Linux is really starting to get the underlying architecture correct) [12:33] Yeah [12:34] Unfortunately, that feature hasn't been ported to my drivers yet. [12:35] We'd still have time to make that feature consistent by the Hardy release. Could boast about it in the release notes. [13:54] * Keybuk tries to work out what the dbus marshalling code should actually look like [14:52] it'd be nice if a method just looked likt [14:52] int [14:53] dbus_job_start (Job *job, [14:53] char **env) [14:53] { [14:53] /* do stuff to start the job, or nih_error_raise */ [14:53] } [14:53] and there was auto-generated wrapper code to marshal the function call, and generate the reply [14:54] not sure how to handle errors though [14:58] since NihError and DBusError don't quite 1:1 match [15:16] Keybuk: that reminds me. We've had to patch nih so that it would recognize rpm tempfiles as package manager files (and thus upstart would ignore them in event.d) [15:16] do you want that upstream? [15:16] yeah, definitely [15:17] Keybuk: if I am not careful, is it possible to end up with a circular start-stop relationship? :D [15:17] jdong: sure [15:17] foo: [15:17] start on stopped bar [15:17] stop on started bar [15:17] bar: [15:17] start on stopped foo [15:17] stop on started foo [15:18] cool :) [15:18] Keybuk: a less silly question, are there any plans/ideas for revamping initramfs with something upstart related? [15:18] general idea is that /sbin/init in the initramfs is upstart [15:18] and you copy the bits of /etc/event.d you want in too [15:19] Keybuk: it seems like rigth now more than 1/3 of my bootup is in initramfs and I can't help but think it can be done more efficiently [15:19] hand-over by reexec, it would pass the job configuration over as "deleted jobs" [15:19] sounds cool [15:19] so the upstart in the real system would know the status/pid/etc. of those started in initramfs [15:19] what's the Ubuntu timeline for having more stuff done by Upstart? Next cycle? [15:20] yeah [15:20] awesome, I really look forward to it. Hacking my Hardy box to boot off upstart has been one of the more exciting things I've done recently [15:20] Keybuk: also, what kinds of files are ignored in event.d? [15:21] Keybuk: check your email. you have a patch [15:21] jdong: hidden files, backup files, swap files, RCS control files and packaging debris [15:21] Keybuk: very nice [15:22] Keybuk: does Upstart understand subdirectory structure in event.d? [15:22] yes [15:22] does it have any special meaning, or can I arbitrarily use it to organize my job files? [15:22] arbitrary organisation [15:22] the /etc/event.d/foo/bar/baz file defines a job called foo/bar/baz [15:22] cool [15:23] Keybuk: also, is there a way for sysv jobs to interact with upstart, such as automatic firing of events for when sysv jobs start/stop? [15:23] other than hacking /etc/init.d/rc :) [15:24] why is not hacking rc important? [15:24] I'd just hack rc to emit sysv-started and sysv-stopped at appropriate times [15:24] Keybuk: just wondering if there's any standardized way yet. I have no problem hacking rc if that's the right way(tm) [15:24] jdong: that's how we're doing it in Fedora [15:25] Keybuk: could this also be an upstart-compat-sysv feature for Intrepid? [15:25] sadmac2: yeah, I'll do that locally for now [15:33] Keybuk: I'm thinking that some time very shortly after 0.5 NetworkManagerDispatcher could be replaced entirely by upstart. [15:40] brb moving desk [17:01] I can't decide which is better [17:01] changing NihError to have some kind of dbus-compatible error string [17:01] or having a look-up table to convert between NihError enums and DBusError strings [17:55] thought-of-the-day [17:56] should the Start() method return immediately, or not return until the service is running/task is finished? === kylem_ is now known as kylem [22:06] keybuk: I’m not familiar enough with how dbus APIs generally behave to give an opinion. [22:06] me neither [22:06] you basically expose objects [22:06] objects have interfaces [22:06] interfaces have methods [22:06] so that's all well and good [22:06] Upstart has JobConfigs and Jobs [22:06] (or Jobs and Instances, depending on the direction I'm explaining from :p) [22:07] so in theory, these should map well [22:07] we'd have a /com/ubuntu/Upstart object with a com.ubuntu.Upstart.Manager interface [22:08] that has a FindByName(String name) -> (Object) method [22:08] obviously that's going to return a Job object [22:09] to start a Job, you need to find or create an Instance, then start that Instance [22:09] it can fail because you didn't supply enough parameters to identify an Instance [22:09] it can fail because the Instance was already started [22:10] if you start a job, you probably want to also be notified of its goal and status changes (initctl does anyway) [22:10] and you want to be notified when it is actually started, or the starting failed [22:10] Yeah [22:11] the goal and status changes are clearly Signals [22:11] you have to tell D-Bus that you want a signal, so this wouldn't work: [22:11] job = FindByName("apache") [22:11] instance = job.Start(...) [22:12] dbus.AddMatch(instance, "StatusChanged") [22:12] since you have a race between the Start and the AddMatch where you'll miss signals [22:12] Yep [22:12] Fix dbus API? :-P [22:12] you only want the signals from the instance you're going to start [22:12] you don't care about the other running apache instances [22:13] (and jobs don't have goals or status anyway) [22:15] we could expose the entire process to the client, and let it do the hard work [22:15] * ion_ envisions the DBus API taking a Ruby-style block, which is executed *after* the object is created but *before* the command has been sent, i.e. instance = job.Start(...) {|it| dbus.AddMatch(it, "StatusChanged") } [22:15] but I think that's generally bad [22:17] so my idea was to have a magic D-Bus "request" object [22:17] job = FindByName("apache") [22:17] request = job.Start(...) [22:17] dbus.AddMatch(request, "StatusChanged") [22:17] request.Go() [22:17] Yeah, that would be equivalent (without the syntactic sugar). :-) [22:30] though I guess it should be StartRequest(...) [22:30] since Start() would do it without an intermediate object [22:32] and almost everything other than initctl will just use Start()