| 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:24 |
| 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 | 00:33 |
| === AlexExtr` is now known as AlexExtreme | ||
| 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:48 |
| Keybuk | which wraps libdbus and makes it less itchy | 10:49 |
| Keybuk | http://people.ubuntu.com/~scott/nih-dbus.png | 10:54 |
| Amaranth | neat, didn't realize you were that far | 11:09 |
| Amaranth | but i thought libdbus aborted when the daemon went away | 11:09 |
| Keybuk | I fixed that | 11:18 |
| 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:20 |
| Amaranth | ah, neat | 11:21 |
| 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:22 |
| Keybuk | : | 11:23 |
| Keybuk | nih_dbus_register_object (job, job_path (job), job_interfaces); | 11:23 |
| 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:24 |
| 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:26 |
| 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:27 |
| Amaranth | i thought nih_free just lowered the reference count | 11:28 |
| Keybuk | no, nih_alloc isn't refcounting | 11:28 |
| Amaranth | ah | 11:29 |
| Keybuk | some bits of dbus seem a bit broken to me | 11:31 |
| 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:32 |
| Keybuk | one to the bus | 11:33 |
| Keybuk | and one for when the bus isn't there | 11:33 |
| Amaranth | ah, for initctl? | 11:34 |
| Keybuk | right | 11:34 |
| Keybuk | try: | 11:35 |
| Keybuk | bus = dbus.SystemBus() | 11:36 |
| Keybuk | manager = bus.get_object("com.ubuntu.Upstart", "/com/ubuntu/Upstart") | 11:36 |
| Keybuk | except: | 11:36 |
| 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:37 |
| 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:38 |
| 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 | 11:39 |
| Keybuk | *sigh* | 14:39 |
| Keybuk | D-Bus needs a lot of glue | 14:39 |
| 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:40 |
| 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:41 |
| 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:44 |
| jdong | cool | 14:45 |
| 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:46 |
| Keybuk | pre-stop will be run | 14:47 |
| Keybuk | the stopping event for the job will be emitted | 14:47 |
| 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:48 |
| 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:49 |
| 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:52 |
| 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:53 |
| Keybuk | why would you do it in pre-start ? | 14:54 |
| 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:55 |
| Keybuk | not really insane, per-se | 14:56 |
| Keybuk | it's certainly one way to do tasks | 14:57 |
| Keybuk | though "started readahead" implies readahead is still ongoing to me | 14:57 |
| Keybuk | whereas "stopped readahead" says that the readahead has actually finished | 14:58 |
| 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:00 |
| Keybuk | sadmac2: happily that's pretty stable ;) | 15:02 |
| Keybuk | obviously it all changes in 0.5 again <g> | 15:02 |
| sadmac2 | well that'll be nice | 15:03 |
| sadmac2 | I'm just hoping I don't miss any features. | 15:03 |
| jdong | Keybuk: lazy question of the day: Is there syntactic sugar for restarting services yet? | 15:14 |
| Keybuk | not yet | 15:16 |
| Keybuk | it's actually more than sugar | 15:16 |
| Keybuk | restart has different behaviour than stop && start | 15:16 |
| sadmac2 | bounce <job> | 15:17 |
| * sadmac2 would be very happy if the command were called bounce | 15:17 | |
| 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:18 | |
| * jdong plays with nice/ionice :) | 15:19 | |
| sadmac2 | Keybuk: bounce is a pretty ubiquitous colloquial term around here for restarting something. | 15:19 |
| * Keybuk wonders whether it's against the rules to name a computer after a game that's not yet been released | 16:01 | |
| sadmac2 | Keybuk: what game? | 16:42 |
| Keybuk | spore | 16:47 |
| Keybuk | makes a good machine name | 16:47 |
| Keybuk | (my naming scheme is computer game names) | 16:47 |
| sadmac2 | Keybuk: the firewall has to be named Portal. | 16:48 |
| sadmac2 | I name mine after postmodernists | 16:48 |
| sadmac2 | Baudrillard, Warhol, Foucault | 16:48 |
| Keybuk | heh, the firewall used to be frontier ;) | 16:49 |
| sadmac2 | The windows box should be Solitare | 16:50 |
| sadmac2 | (sp?) | 16:50 |
| sadmac2 | s/tar/tair/ | 16:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 16:59 |
| mdales | hmmm | 17:00 |
| mdales | the script is still there and is valid | 17:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| jdong | Keybuk: does Upstart log anywhere? | 17:04 |
| jdong | I think I have a race on boot :) | 17:04 |
| Keybuk | to syslog | 17:05 |
| Keybuk | mdales: right, it won't become available if Upstart has wiped it from its memory | 17:05 |
| jdong | Keybuk: does console output imply not console logged? | 17:09 |
| 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:12 |
| mdales | not much new info on debug. I can see that on start the process in question respawns and then terminates a lot | 17:13 |
| 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:14 |
| Keybuk | "deleted" is a clue ;) | 17:15 |
| 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:16 |
| Keybuk | it might be happening before syslog starts | 17:17 |
| mdales | ah. alas it scrolls off too quickly | 17:17 |
| mdales | 25 lines really isn't enough :) | 17:19 |
| 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:20 |
| mdales | this was a reboot without debug | 17:21 |
| 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:22 |
| 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:23 |
| * 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:24 |
| ion_ | I don’t even have a caps lock light. :-) | 17:25 |
| mdales | with --debug there's just too much crap | 17:28 |
| mdales | well, many thanks for the assistance. if I find any more info I'll file a bug perhaps :) | 17:30 |
| Keybuk | do you know, I think I just won? | 17:40 |
| 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:41 |
| Keybuk | heh, I've stopped it biting me | 17:42 |
| Keybuk | I haven't yet got a saddle on it | 17:42 |
| ion_ | Heh | 17:44 |
| Keybuk | of course, now to decide which bit to attack next | 18:08 |
| * sadmac2 attacks the crab's weak point for massive damage | 19:53 | |
| 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. | 19:57 |
| * Keybuk wonders | 21:28 | |
| sadmac2 | ...???!!! | 21:28 |
| sadmac2 | what? what? | 21:28 |
| Keybuk | which bit to do next | 21:30 |
| sadmac2 | Keybuk: what are the options? | 21:30 |
| 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:31 |
| sadmac2 | which bindings are those? | 21:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| sadmac2 | I dunno. I'd need a fuller picture of what's going on. | 21:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| sadmac2 | sigsetjmp was behaving oddly though. | 21:45 |
| Keybuk | you can certainly do exceptions in C | 21:45 |
| Keybuk | cf. dpkg | 21:45 |
| ion_ | A human can be considered a code generator. :-P | 21:57 |
| ion_ | Or perhaps a caffeine to code converter. | 21:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
