[01:20] sadmac_: yes [01:21] though in 0.3.x it will probably contain the event that stopped the job [01:21] whereas in trunk, UPSTART_EVENTS will contain the events that originally started it [12:08] Hi [12:16] hi [12:24] The chance I wil use upstart are growing every day :p [12:25] I am now looking into the kernel->upstart communication [12:28] special I am looking at the udev from the replacement-initscripts http://paste-it.net/7162/raw/ [12:29] that script has a "emits block-device-added block-device-removed" section [12:32] what it that good for? [12:32] "emits" is just a documentation stanza [12:33] you'd use it in the job definitions of services that are known to emit their own events [12:33] and that way other frontend tools can draw pretty dependency graphs using things like dotty [12:33] sexy :p [12:33] it's not actually used by Upstart in any way, other than being available as a property [12:34] the theory there is that that distribution would ship udev rules that looked something like: [12:34] SUBSYSTEM=="block", ACTION=="add", RUN+="/sbin/initctl emit block-device-added DEVPATH" [12:34] SUBSYSTEM=="block", ACTION=="remove", RUN+="/sbin/initctl emit block-device-removed DEVPATH" [12:35] SUBSYSTEM=="net", ACTION=="add", RUN+="/sbin/initctl emit network-device-added INTERFACE" [12:35] SUBSYSTEM=="net", ACTION=="remove", RUN+="/sbin/initctl emit network-device-removed INTERFACE" [12:35] etc. [12:35] alternately we may want an upstart-addon-udev or something so we could have a generic RUN+="socket:/com/ubuntu/upstart/udev" at the end, and let the addon daemon turn those into events [12:35] OR we might just patch udev directly to emit events into upstart [12:37] my system does not use udev, i currently use to recieve NETLINK_KOBJECT_UEVENT events [12:38] I could just create a mini app that gets started and emits the kernel uevent [12:40] hmm I will look into it [12:43] right [12:43] you could have a little daemon to listen on the netlink socket and inject into upstart [12:44] I do have the same kind of problems that are solved by udev , being that if a device get plugged before the daemon is started I will never know about [12:45] I then have to write custom code to look at the status . [12:56] why not just write to the uevent files like udev does? [12:56] for each object under /sys that a uevent was originally emitted for, there will be a uevent file [12:56] write "add" (no \0, no \n, etc.) to that, and the kernel will resend it [13:03] Thanks for the tip , I will have to look into how that works! [19:12] ion_: interesting thought of the day [19:12] all of the dbus_bus_ calls block [19:17] keybuk: Is that a problem? [19:18] I'm not sure [19:20] the fact that dbus_bus_get() can never return worries me enough :p [19:20] Heh [19:23] I guess it depends at what level of blocking we have to worry about in Upstart [19:24] in some senses, blocking is actually not necessarily bad [19:24] since it reduces system load [19:24] e.g. upstart blocks while it sets up a process, even though that's happening the child [19:24] and doesn't move onto the next until exec() completes [19:24] so arguably, after starting dbus, blocking to connect to it and say Hello isn't too bad [19:40] Yep... [19:56] Don’t they have a separate DBus (client) implementation in C#? Perhaps someone should NIH a DBus implementation that doesn’t suck in C. ;-) [19:56] ndesk-dbus [20:01] the C API isn't really that bad [20:01] the main problem is just figuring out how to dispatch methods [20:14] ion_: that would be great [21:17] @btlogin [21:17] err