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