On Thu, Mar 24, 2011 at 10:20 AM, Tom Gundersen <teg@jklm.no> wrote:
On Thu, Mar 24, 2011 at 2:44 AM, Seblu <seblu@seblu.net> wrote:
# Run helper every time a Bluetooth device appears # On remove actions, bluetoothd should go away by itself ACTION=="add|change", SUBSYSTEM=="bluetooth", RUN{fail_event_on_error}+="/usr/sbin/bluetoothd --udev"
And after booting (so after dbus is running), calling "/sbin/udevadm trigger --action=add --type=failed" manually? That's works. But as you said, it is now removed from upstream.
Hm, at least we know exactly where the problem is. But, it will not work for long I guess.
I guess this is a bluez bug then. It seems that it is not allowed to fail anymore.
Have you seen this commit and accompanying bug report: <http://git.kernel.org/?p=bluetooth/bluez.git;a=commit;h=7bf4b08d0bd35aaef50926e14c5be277df3550e2>? It seems this was a problem for Fedora 14, and that it was fixed in bluez.
If i understand correctly, issue was about an udev new behaviour which use "change" event instead of "add" in some way.
Yeah, it was not discussed there. You could also try the bluez mailinglist perhaps?
Tom do you see answer in linux-hotplug mailing list? My understanding: Let initscripts start bluetoothd and not udev (it should not use to manage services). Regards, -- Sébastien Luttringer www.seblu.net