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