[00:24] another idea [00:24] req = com.ubuntu.Upstart.Request () [00:24] job = FindByName("apache") [00:24] dbus.AddMatch(req, "StatusChanged") [00:24] instance = job.Start(env, req) [00:33] or I guess [00:33] job = FindByName("apache") [00:33] req = job.Request() [00:33] dbus.AddMatch(req, "StatusChanged") [00:33] req.Start(env) [00:33] basically pre-alloc the Request object === AlexExtr` is now known as AlexExtreme [10:48] oh, DBus [10:48] * Keybuk has a KHAAAAAAAN! moment [10:48] so are you writing your own libdbus now? :) [10:48] basically [10:48] well [10:48] libnih-dbus [10:49] which wraps libdbus and makes it less itchy [10:54] http://people.ubuntu.com/~scott/nih-dbus.png [11:09] neat, didn't realize you were that far [11:09] but i thought libdbus aborted when the daemon went away [11:18] I fixed that [11:20] how? :) [11:20] reimplemented dbus_bus_get() [11:20] otherwise it's just a flag in the struct you leave as FALSE [11:21] ah, neat [11:22] at the point of chaining everything together [11:22] so you do something like: [11:22] NihDBusInterface job_interfaces[] = { [11:22] IFACE_JOB, [11:22] { NULL } [11:22] }; [11:23] : [11:23] nih_dbus_register_object (job, job_path (job), job_interfaces); [11:24] IFACE_JOB, and all the necessary marshalling functions, are generated by a python script [11:24] so you just need to define [11:24] job_start() and job_stop(), etc. [11:24] which have C-like arguments and return values [11:24] that's pretty neat [11:26] main problems are the difference in interface style ;) [11:26] e.g. that function creates an NihDBusObject struct, holding the path, interface array and underlying object [11:26] for bus, that needs a vtable structure - the message function is a standard one inside libnih-dbus that knows how to dispatch based on the interface array [11:27] (and handle the Introspect and Properties interfaces) [11:27] the unregister function is a standard one as well [11:27] so when the connection vanishes, it calls nih_free() on the object [11:27] *but* that means if you call nih_free yourself, the destroy function has to unregister the object [11:27] which calls the unregister function [11:27] which is nih_free [11:27] i think i'll just keep using dbus from python :P [11:28] i thought nih_free just lowered the reference count [11:28] no, nih_alloc isn't refcounting [11:29] ah [11:31] some bits of dbus seem a bit broken to me [11:32] or, at least, poorly designed [11:32] you say that about everything, i think :P [11:32] like the fact you can't share an object table between multiple dbus connections ;) [11:32] multiple connections? why would you have multiple connections? [11:33] one to the bus [11:33] and one for when the bus isn't there [11:34] ah, for initctl? [11:34] right [11:35] try: [11:36] bus = dbus.SystemBus() [11:36] manager = bus.get_object("com.ubuntu.Upstart", "/com/ubuntu/Upstart") [11:36] except: [11:37] server = dbus.connection.Connection("unix:abstract=/com/ubuntu/Upstart") [11:37] manager = server.get_object("/com/ubuntu/Upstart") [11:37] neat [11:38] though in practice, most things will be discouraged from doing the fail-over [11:38] it's mostly just for initctl, so if dbus is down, you can either start dbus - or shutdown the machine [11:38] i can't think of anything else that would need it [11:38] me neither [11:39] well, i'm sure people will _think_ they should use it [11:39] but you can just tell them to quit being stupid and start the system bus :) [11:39] yeah [14:39] *sigh* [14:39] D-Bus needs a lot of glue [14:40] you could write an UpstartBus and expose some Dbus compatibility mode for a few release cycles ;-) [14:40] you know that sounds tempting [14:40] then the KDE4 folks will have a real world justification for their dbus abstraction layer! [14:41] we had an upstart-native IPC before [14:41] that's what I'm trying to get away from [14:41] :p [14:44] Keybuk: What kind of {pre/post}-start/stop events are available to me in Hardy's upstart? [14:44] are post-start and pre-stop logical/existent? [14:44] yes [14:45] cool [14:46] Keybuk: so when 5 jobs "start on stopping bar" and I do initctl stop bar, what is the order of actions that happen from that with regards to pre-stop/post-stop scripts on bar? [14:47] pre-stop will be run [14:47] the stopping event for the job will be emitted [14:48] that event blocks [14:48] the main process of the job will be killed [14:48] post-stop will be run [14:48] the stopped event for the job will be emitted [14:48] Keybuk: beautiful and logical [14:49] no order between the individual 5 jobs is guaranteed [14:49] sounds reasonable. [14:49] but between the 5 jobs and bar *is* guaranteed [14:49] bar will not actually be killed until the 5 jobs have started [14:52] Keybuk: in your replacement-initscripts, is there any reason you chose to not use a service and pre-start/post-stop for readahead, readahead-watch, and other non-daemonized stuff? [14:52] how do you mean? [14:53] Keybuk: like in readahead, you used a single "exec readahead-list blah", while I probably would've used "service; pre-start script readahead-list blah" [14:54] why would you do it in pre-start ? [14:55] Keybuk: so that way readahead shows up as "started" and I can say "start on started readahead" which makes more sense to me than "start on stopped readahead ok" [14:55] Keybuk: is there something insane about doing it in pre-start? [14:56] not really insane, per-se [14:57] it's certainly one way to do tasks [14:57] though "started readahead" implies readahead is still ongoing to me [14:58] whereas "stopped readahead" says that the readahead has actually finished [15:00] (the "ok" is arguably a bug, it shouldn't matter whether it worked or not ) [15:00] Keybuk: We'll be needing to document the 0.3.9 job format soon. [15:02] sadmac2: happily that's pretty stable ;) [15:02] obviously it all changes in 0.5 again [15:03] well that'll be nice [15:03] I'm just hoping I don't miss any features. [15:14] Keybuk: lazy question of the day: Is there syntactic sugar for restarting services yet? [15:16] not yet [15:16] it's actually more than sugar [15:16] restart has different behaviour than stop && start [15:17] bounce [15:17] * sadmac2 would be very happy if the command were called bounce [15:18] heh, why? :) [15:18] wouldn't that clash with MTA commands? [15:18] because he can create innuendos with jobs like "fsck" [15:18] jdong: you're one to talk, what with having dong in your name and all [15:18] not like he can't do that right now, already. [15:18] * jdong goes down the road of greedy boot speed optimization. [15:19] * jdong plays with nice/ionice :) [15:19] Keybuk: bounce is a pretty ubiquitous colloquial term around here for restarting something. [16:01] * Keybuk wonders whether it's against the rules to name a computer after a game that's not yet been released [16:42] Keybuk: what game? [16:47] spore [16:47] makes a good machine name [16:47] (my naming scheme is computer game names) [16:48] Keybuk: the firewall has to be named Portal. [16:48] I name mine after postmodernists [16:48] Baudrillard, Warhol, Foucault [16:49] heh, the firewall used to be frontier ;) [16:50] The windows box should be Solitare [16:50] (sp?) [16:50] s/tar/tair/ [16:51] yeah, used that one a few years ago [16:51] mine are named after characters from The Matrix [16:51] it was replaced by minesweeper and now is hearts [16:52] I have a quick question. If I remember correctly upstart will blacklist any script that fails too frequently within a given period [16:52] at any point does that blacklisting expire? [16:53] depends on the period [16:53] it's a rate limit [16:53] if you say a job can only respawn 10 times a minute, then it cannot respawn within a minute of the first of 10 respawn attempts [16:54] the default is 5 times in 10 seconds [16:54] hmmm [16:54] okay [16:54] what's happening here is an ubuntu system has had a bad udev rule added that means a job is being invoked too early in the boot process, rather than waiting for runlevel 2 [16:55] so it fails, then at runlevel 2 the rule is no longer available [16:55] which "here" is this? [16:55] udev doesn't emit any upstart events in Ubuntu [16:56] it's a gutsy system that I don't have ssh access too, just through the software that is started by this upstart job [16:56] what software is that? [16:56] well, that's the pain - someone accidently made udev to it [16:56] some remote management software I wrote [16:56] right [16:56] and that crashed? [16:57] I imagine the software crashed as the world wasnt' ready. the udev rule restarts the software on block devices (intended for USB stick configuration) [16:57] ok [16:57] so I assume it's being started on hard disks :) [16:57] definitely would be, yes [16:58] we get an unknown job error on the system we've reproduced the error on here [16:58] but I was wondering if we waited long enough that would go away [16:59] unknown job is odd [16:59] that means the name isn't right? [16:59] they're only stopped if they run out of control [16:59] not deleted [17:00] hmmm [17:00] the script is still there and is valid [17:01] I say, the runaway invocation was just a theory [17:01] does status not show it? [17:01] initctl list does not show it [17:01] what happens if you touch it? [17:01] touch /etc/event.d/myjob [17:01] does it show up in list? [17:01] let me see [17:02] yes [17:02] it does [17:02] Upstart thinks you deleted the file [17:02] cool :) [17:02] is it changed at all on boot? [17:02] no [17:03] the only thing this udev script does is call start and stop [17:03] weird [17:03] in that it tries to stop an existing thing and then start it [17:03] I'd boot with --debug to see what's going on [17:03] will give that a whirl. but I'm assuming my theory that the job would become avaiable over time is bogus then? [17:04] Keybuk: does Upstart log anywhere? [17:04] I think I have a race on boot :) [17:05] to syslog [17:05] mdales: right, it won't become available if Upstart has wiped it from its memory [17:09] Keybuk: does console output imply not console logged? [17:12] console logged is broken [17:12] Keybuk: would that be why /var/log/boot is empty? [17:12] yes [17:12] cool :) [17:13] not much new info on debug. I can see that on start the process in question respawns and then terminates a lot [17:14] odd that upstart deleted it though [17:14] it should mention that [17:14] I can't see it - is there a specific term I should be scanning for in the logs? [17:15] "deleted" is a clue ;) [17:16] there should certainly be something like: [17:16] Deleting foo job [17:16] cd /var/log; grep elete * | grep job shows no results [17:16] did you look at the output on the screen? [17:17] it might be happening before syslog starts [17:17] ah. alas it scrolls off too quickly [17:19] 25 lines really isn't enough :) [17:20] okay, so this is interesting. I actually start two processes, the second dependant on the first. it's the first that's being deleted. I note the second gets too many restarts, but the first only seems to be started once [17:20] ther'es a terminate message, then silence [17:21] this was a reboot without debug [17:22] We really should move the drivers from Xorg to the kernel, have it provide a good framebuffer interface with acceleration, resolution settings et al, and have the virtual consoles as well as X use the same framebuffer interface in harmony. :-) [17:22] heh [17:22] I assume then it says job terminated with status 2 the 2 is the exit status for the process [17:23] That would also make it possible for X to break horribly and still have a working console, or even a kernel’s debug console you get with a magic sysrq key over virtual consoles as well as X. [17:23] mdales: yes [17:23] ion_: it makes it possible to panic the kernel and do something more useful than flash the caps lock light ;) [17:23] (I kid you not, this is in keithp's use case list) [17:23] Yep :-) [17:24] * AlexExtreme hates not getting panic info when in X [17:24] btw, is kdump going to be used in ubuntu any time soon? [17:25] I don’t even have a caps lock light. :-) [17:28] with --debug there's just too much crap [17:30] well, many thanks for the assistance. if I find any more info I'll file a bug perhaps :) [17:40] do you know, I think I just won? [17:41] still need to handle new connections, disconnection and properties [17:41] but the basics are there now ... [17:41] Congrats. :-) [17:41] You tamed the beast. [17:42] heh, I've stopped it biting me [17:42] I haven't yet got a saddle on it [17:44] Heh [18:08] of course, now to decide which bit to attack next [19:53] * sadmac2 attacks the crab's weak point for massive damage [19:57] ion_: there's quite a few X developers here at RH that want to do what you want to do with X, and similar things. [21:28] * Keybuk wonders [21:28] ...???!!! [21:28] what? what? [21:30] which bit to do next [21:30] Keybuk: what are the options? [21:31] still just plodding on with the dbus stuff [21:31] I guess I need to work on the python script to auto-generate the bindings [21:34] which bindings are those? [21:35] basically just C marshalling functions [21:35] to turn DBusMessage into a function call, and vice-versa [21:35] auto-generating code makes kitty scared. But I won't judge without seeing. [21:36] really? [21:36] auto-generating code is the *best* way to do things [21:36] since then you only need test the generator [21:37] The better way is to be really smart about de-duplication, so you just don't have to write much code. [21:37] sadly the C compiler doesn't yet support runtime-generated function calls ;) [21:37] I suppose the cpp is auto-generation though. And I do love the cpp. [21:38] well, you'd still have to do the generating before compile time, wouldn't you? [21:38] it doesn't even support that [21:39] I dunno. I'd need a fuller picture of what's going on. [21:40] int [21:40] hello_world (const char *who, [21:40] const char **str) [21:40] { [21:40] sprintf (*str, "hello %s", who); [21:40] return 0; [21:40] } [21:41] ideal C code for a D-Bus method with the IDL [21:41] com.netsplit.Nih.Test.HelloWorld (in String who, out String str) [21:41] to be able to make the code that simple, you need a function to marshal a DBusMessage into a function call [21:41] and form a valid reply as well [21:42] people.ubuntu.com/~scott/test_dbus.c [21:42] err [21:42] http://people.ubuntu.com/~scott/test_dbus.c [21:42] test_hello () there is the example of the simple function I'd like to spend my time writing [21:43] the test_hello_marshaller () function makes it possible by marshalling the message [21:43] and the test_hello_args, test_methods, test_signals, test_properties and test arrays connect it all together [21:43] I'd like everything but test_hello() to be autogenerated [21:43] since it's entirely based on the iDL [21:44] I see. [21:44] I think I could get nearly there using just the cpp. [21:44] it'd be quite difficult [21:44] :) I was damn close to having try {} catch {} blocks implemented in the cpp. [21:45] sigsetjmp was behaving oddly though. [21:45] you can certainly do exceptions in C [21:45] cf. dpkg [21:57] A human can be considered a code generator. :-P [21:57] Or perhaps a caffeine to code converter.