| hadess | Keybuk: around? | 10:39 |
|---|---|---|
| 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:42 |
| Keybuk | to answer your second not-quite-question first | 10:43 |
| Keybuk | boot with --debug on the kernel command line | 10:43 |
| hadess | ok, doesn't make for easy debug switching on an already started machine | 10:45 |
| Keybuk | 0.3.x or 0.5.x ? | 10:46 |
| Keybuk | try "initctl log-priority debug" | 10:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| hadess | as the helper also dumps junk into a temp file, and that got updated | 10:51 |
| hadess | could bluetoothd forking as a daemon break things? | 10:52 |
| Keybuk | yes | 10:52 |
| Keybuk | upstart will think it has died | 10:52 |
| 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:53 |
| hadess | that's not really a problem for me here though | 10:54 |
| hadess | nope, still not working | 10:56 |
| hadess | i wonder where the syslogd config lives these days | 10:57 |
| hadess | there's a bug in my rules | 10:58 |
| 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 | 10:59 |
| Keybuk | ah | 11:08 |
| hadess | you wouldn't happen to know how to defer that call slightly? | 11:10 |
| 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:11 |
| hadess | i'll discuss those with kay | 11:12 |
| hadess | thanks for the help! | 11:12 |
| Keybuk | yeah, udev runs when the root is still r/o | 11:14 |
| hadess | Keybuk: got it running, any ideas why it stops it straight away here: http://pastebin.com/m5cf62c70 ? | 11:27 |
| 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:28 |
| hadess | weird, not sure why it would be | 11:30 |
| hadess | i'm an idiot :) | 11:30 |
| 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:31 |
| 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:32 |
| soren | Keybuk: So if I need that console to be there for the Karmic release, what do I do? | 11:33 |
| soren | Cry? | 11:34 |
| soren | :) | 11:34 |
| Keybuk | soren: how would you do it in sysvinit? | 11:35 |
| Keybuk | create the file in a postinst depending on how being installed? | 11:35 |
| 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:36 |
| 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:37 |
| * soren contemplates a udev rule that installs the job description in /etc/event.d when the hvc0 device pops up | 11:40 | |
| soren | (only joking) | 11:41 |
| Keybuk | filesystem is read-only when your rule is run | 11:42 |
| soren | Another cunning plan foiled by pesky reality. Darn it. | 11:43 |
| 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) | 22:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!