On Sat, Mar 26, 2011 at 7:29 PM, Seblu <seblu@xxxxxxxxx> wrote: > Tom do you see answer in linux-hotplug mailing list? Thanks for the reminder, I thought I was subscribed, but obviously not... > My understanding: Let initscripts start bluetoothd and not udev (it > should not use to manage services). This was not entirely clear to me. I read the advice as: either use systemd (and do not let udev manage the bluetooth daemon), or retrigger the bluetooth add event when dbus has been (re)started. A third solution is, as you say, to let initscripts manage the bluetooth daemon and remove the functionality from the udev rule. I think maybe the third solution is the cleanest one, but in that case it is an upstream (bluez) bug, as the udev rule file is provided unconditionally (AFAIKS). Actually, I wonder whose benefit the udev rule is supposed to be for: systemd (and similar) should manage bluetooth on its own, so should not have the daemon started by udev, and with a traditional sysvinit system will have the problem that we are faced with now. I think it would be worthwhile to ask the bluez developers what they think is the best solution. Cheers, Tom
