On Fri, 2009-06-12 at 20:44 +0200, Lennart Poettering wrote: > On Fri, 12.06.09 19:26, Bastien Nocera (bnocera@xxxxxxxxxx) wrote: > > > Every time there's an add action for a Bluetooth device, udev will run > > "bluetoothd --udev". > > > > bluetoothd will fail with an error if D-Bus isn't started (on bootup), > > and the udev coldplug (done in udev-post) will run the rule again. > > > > bluetoothd will silently fail when it's already running. > > > > bluetoothd will exit itself after 30 seconds when no adapters are > > present. There's a potential race if the udev add event happens in > > between the time the time the running bluetoothd reliquinshes its D-Bus > > service, and the new one starts up. > > This could be fixed by first releasing the service name synchronously, > then processing all queued requests and only then closing/exiting. > > Hmm, will bluetoothd also be started via bus activation? If so, it > wuld probably make sense to issue a StartByName D-Bus request from the > udev rule and let dbus handle all the ordering/synchronization issues > with starting up bluetoothd. No, there's no service activation support. Would it be useful? > I know at least one application (PA) that wouldn't reconnect to coming > and going bluetoothd's, that's why I am asking. Which is why we're doing it early in F-12. At least obex-data-server is broken as well. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
