2011/3/22 Ng Oon-Ee <ngoonee@gmail.com>:

Any particular reason you cross-posted this between aur-general and arch-general? I got screwed by the auto-completion

On Tue, 2011-03-22 at 03:59 +0100, Seblu wrote:

...

Hello,

It was a few things I could not explain with bluez and udev.

When my system start killswitch off and i toggle killswitch after, bluetoothd is auto started. When my system starts with killswitch on, bluetoothd is not started. (a bit confusing)

After adding hooks in rc, bluetoothd refuse to start at boot because it needs dbus! If I searched on google before trying to debug I saved a few hours: https://bbs.archlinux.org/viewtopic.php?id=112161

And yes, that's the case for most problems...

...

So, this situation is a bit confusing, so why do not remove /lib/udev/rules.d/97-bluetooth.rules? From my test bluetoothd, doesn't kill itself when it's run by /etc/rc.d/bluetooth.

Regards,

-- Sébastien Luttringer www.seblu.net

On Tue, Mar 22, 2011 at 8:44 AM, Tom Gundersen <teg@jklm.no> wrote:

On Tue, Mar 22, 2011 at 3:59 AM, Seblu <seblu@seblu.net> wrote:

...

So, this situation is a bit confusing, so why do not remove /lib/udev/rules.d/97-bluetooth.rules?

I don't think it is a good idea to remove these rules, at they allow bluez to be started on demand rather than unconditionally. I'd rather try to fix it :-) I agree about trying to fix it. But I don't see how to do this except by running a kind of "/sbin/udevadm trigger --action=add" at end of rc.multi.

Could you try running "/sbin/udevadm trigger --action=add --type=failed" after dbus has started?

It does nothing. And that's why I lost time before going to look at why dbus does not start. I feel that udevadm do not realize that launching dbus failed. Maybe based on return code (i don't yet checked). But in any case, if we do not modify the initscripts, the call for errors is done too early. -- Sébastien Luttringer www.seblu.net