[10:39] Keybuk: around? [10:42] i have that event.d script for upstart: http://pastebin.com/m222f649a [10:42] but it doesn't seem to do what it's supposed to, and i don't know how to turn on debug for upstart [10:43] to answer your second not-quite-question first [10:43] boot with --debug on the kernel command line [10:45] ok, doesn't make for easy debug switching on an already started machine [10:46] 0.3.x or 0.5.x ? [10:46] try "initctl log-priority debug" [10:47] upstart-0.3.9-24.fc11.x86_64 [10:47] though i'm trying to get something that'd run on both, and could stick upstream [10:47] 0.3 and 0.5's job syntax isn't compatible [10:48] (nor will 0.10's be compatible with either) [10:48] ok [10:48] well, let's start with 0.3 then [10:48] do i have the idea right for that script for 0.3? [10:49] yes [10:49] as long as something calls initctl emit fedora.bluetooth-adapter-{,not-}available [10:49] any idea why it wouldn't be working? [10:49] it'll be started when an adapter is available [10:50] and stopped when *either* an adapter is no longer available *or* the system is shutdown/entered into single user mode [10:50] i used "initctl emit --no-wait fedora.bluetooth-adapter-available" [10:50] in a udev helper [10:50] ok [10:50] and that bit works [10:51] as the helper also dumps junk into a temp file, and that got updated [10:52] could bluetoothd forking as a daemon break things? [10:52] yes [10:52] upstart will think it has died [10:53] ok, let's fix that already [10:53] exec bluetoothd --no-daemon [10:53] supervision of forking daemons is one of the major features of the upstart-nl branch [10:54] that's not really a problem for me here though [10:56] nope, still not working [10:57] i wonder where the syslogd config lives these days [10:58] there's a bug in my rules [10:59] the helper uses udevadm to list devices, and obviously, when the rule is run, udev doesn't know about the device yet... [10:59] so it emits fedora.bluetooth-adapter-not-available all the time [11:08] ah [11:10] you wouldn't happen to know how to defer that call slightly? [11:11] not on fedora [11:11] notting also told me that i'd get into trouble getting the udev event real early with the root still r/o [11:12] i'll discuss those with kay [11:12] thanks for the help! [11:14] yeah, udev runs when the root is still r/o [11:27] Keybuk: got it running, any ideas why it stops it straight away here: http://pastebin.com/m5cf62c70 ? [11:28] # [11:28] Jun 11 11:26:46 cookie init: bluez main process (4330) terminated with status 1 [11:28] whatever you're running is exiting [11:30] weird, not sure why it would be [11:30] i'm an idiot :) [11:31] Keybuk: I'm not sure I understand your comment on bug 372864. Will there be a better mechanism for doing this in the Karmic cycle? [11:31] Keybuk: awesome, working :) [11:32] soren: definitely [11:32] soren: though it may be quite late in the karmic cycle, like in the next one ;) [11:32] Keybuk: ah :) [11:32] but certainly not worth trying to come up with an upstart-y way of doing it now, if I'm doing a ground-up rewrite/redesign of Upstart ;) [11:32] about the point you get it working, I'll break it again [11:33] Keybuk: So if I need that console to be there for the Karmic release, what do I do? [11:34] Cry? [11:34] :) [11:35] soren: how would you do it in sysvinit? [11:35] create the file in a postinst depending on how being installed? [11:36] Keybuk: I was hoping not to have to do anything like that. [11:36] Keybuk: So far, I've managed to not have to special case anything for kvm based virtual machines. [11:37] In the sense of installing additional packages to make stuff work, that is. [11:37] I'd really, really like to keep it that way. [11:37] I don't know how I'd have done it in the old days with plain old sysvinit. [11:40] * soren contemplates a udev rule that installs the job description in /etc/event.d when the hvc0 device pops up [11:41] (only joking) [11:42] filesystem is read-only when your rule is run [11:43] Another cunning plan foiled by pesky reality. Darn it. [22:36] Is it possible for an upstart job to grab control of the init process and demand some input before continuing? (In my case, insisting a password is entered to decrypt a filesystem)