=== h\h is now known as haraldh [15:42] Is there a way to listen to upstart events? [15:44] like the initctl events [15:44] keesj: not anymore [15:44] bugger [15:49] I guess the "new" way of doing this would be to use dbus right? [15:52] keesj: doing what exactly? [15:54] I would like to supervise the events happening in upstart [15:55] mainly services stopping / crashing and such [15:55] yes. dbus should get you that. [15:57] with or without upstart hacking? [15:57] without [15:59] lets kick dbus-monitor then :P thanks [16:11] dbus won't get you that [16:13] Keybuk: we have signals for "service up" and "service down" don't we? [16:14] or at least you can watch for new/vanishing objects [16:27] right [16:27] there are signals for that kind of thing [16:28] just not generic events [16:28] Keybuk: yeah. so dbus gets him what he was fundimentally interested in seeing. [16:28] right [16:29] keybuk: If you have a bit of free time, would you mind satisfying my curiosity by explaining how you’ve figured Upstart 0.6 would handle the fsck+mount thing? :-) [16:29] s/explaining/describing/ [16:31] oh, that's easy [16:31] you have a udev rule that parses fstab, and fills in the details [16:31] then you have an upstart job that matches those details [16:31] which calls mount [16:31] and then parses fstab again, and emits a can-mount event for anything underneath it [16:31] start on (block-device-added [16:32] and can-mount $DEVNAME [16:32] exec mount $DEVNAME [16:32] post-stop exec what-can-we-mount $DEVNAME [16:32] etc. [16:32] How will you handle blocking fsck instances that work on the same physical device? [16:33] you can do that with simple locking [16:36] I have the prototype sh code that does some /sys traversing to get from /dev/some-lvm-device to some-md-device to [sda/sda1, sdb/sdb1] to [sda, sdb] somewhere. I could finish it; it could be used to get the list of names for the locks. [16:39] flock(1) from util-linux could be useful here. It would need to be moved from /usr/bin to /bin, though. [16:43] the problem with the pure-upstart case though is how inefficient it is [16:43] you have to keep on re-parsing fstab [16:44] Are you going to implement that for karmic nevertheless? [16:44] no [16:45] for karmic, I'm going with the "program that calls fsck, mount and swapon in the right order" approach [16:50] Ok === robbiew is now known as robbiew-afk === robbiew-afk is now known as robbiew [20:11] upstart have a 'user' option yet? [20:12] wasabi: no. [21:22] There a dh_* to install job files? [21:24] wasabi: I don't think I know what that is. Is it debian-related? [21:24] Yeah [21:24] 2008-10-15 17:46:28 < Keybuk> suihkulokki: I do not think dh_ anything is a good idea [21:24] 2008-10-15 17:46:42 < Keybuk> what's wrong with just shipping the file as a conffile? [21:25] Nothing. That's what I'm doing. [21:25] Just wondering. I like dh_ stuff.