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