Created attachment 331113 [details] udev rule Description of problem: Currently we start the bluetooth service by an initscript, which we install and enable for everybody by default, even if they are no bluetooth devices present. With a simple udev rule and a shell script we can only start the service ondemand (when a device is inserted) I will attach both to this bug for review.
Created attachment 331114 [details] shell script to be placed in /lib/udev
ping?
The problem is that this will break a number of long-running applications and services. It will break obex-data-server, though that's probably an obex-data-server bug. I believe there would be more broken services, though I can't think of any on top of my head right now.
Can't we start bluetoothd by dbus activation too, so that anything trying to use its services will work? I think the script in comment #1 should probably use 'service bluetooth status' to determine whether bluetoothd is running, rather than 'pidof bluetoothd'? And it doesn't seem to work well with runlevel changes. When we enter a runlevel in which bluetoothd should be enabled, we should start it _if_ there is bluetooth hardware present. And when we enter a runlevel where bluetoothd should be dead, we should kill it if it's running.
This looks like we have to define a mechanism which depends on hardware presence and runlevel configuration for service actions.
(In reply to comment #4) > Can't we start bluetoothd by dbus activation too, so that anything trying to > use its services will work? We tried doing that (in the hcid days), and it was completely and utterly broken, and nobody bothered to report bugs. bluetooth-applet and a number of other services won't auto-start it, given the way they try to get the manager object. It would also defeat checking the presence of bluetoothd, as we'd end up starting bluetoothd when no hardware is present. > I think the script in comment #1 should probably use 'service bluetooth status' > to determine whether bluetoothd is running, rather than 'pidof bluetoothd'? Agreed. > And it doesn't seem to work well with runlevel changes. When we enter a > runlevel in which bluetoothd should be enabled, we should start it _if_ there > is bluetooth hardware present. And when we enter a runlevel where bluetoothd > should be dead, we should kill it if it's running.
Well, maybe you could put that in the initscript. If asked to start the service and there's no hardware present, do nothing. That way, the udev script above should do the right thing. All we need to handle then is dbus activation.
My 2 cents, have you guys seen work done by Petr Lautrbach .. https://bugzilla.redhat.com/show_bug.cgi?id=487665
Unless somebody has time to fix all the potential bugs that'll trickle down from this change, this won't get into F11. Too busy with other things to fix up already. I'm waiting for patches for F12 though.
Created attachment 334279 [details] start and stop service on demand based on udev events it's against cvs bluez/devel. adds two files together with spec file and sysconfig file changes bluetooth.event.d - upstart instance bluez-upstart-udev-rules.patch - adds udev rules Patch idea: Udev rules emit bluetooth-start or bluetooth-stop based on udev event action. Upstart instance waits for these events or for runlevel change. Service is automatically started if: (udev event is "ACTION==add SUBSYSTEM==bluetooth" or runlevel changed) and UPSTART_ENABLE=true in /etc/sysconfig/bluetooth and service is enabled in current runlevel and service is stopped Service is automatically stopped if: (udev event is "ACTION==remove SUBSYSTEM==bluetooth" or runlevel changed) and UPSTART_ENABLE=true in /etc/sysconfig/bluetooth and service is enabled in current runlevel and service is running and no bluetooth device left in system
src.rpm: http://plautrba.fedorapeople.org/bluez/bluez-4.32-1.1.fc10.src.rpm
Hi. Simpler idea without upstart instance: http://plautrba.fedorapeople.org/bluez/4.32-1.2/ bluetooth.init has new targets - condstart, condstop condstart, condstop - work only if set BLUETOOTH_ONDEMAND=true and always check condition - called from /etc/udev/rules.d/97-bluetooth-ondemand.rules start - if set BLUETOOTH_ONDEMAND=true checks condition, else always start - called by user, after boot or runlevel change stop - always stop - called by user, after boot or runlevel change BLUETOOTH_ONDEMAND - may be set in /etc/sysconfig/bluetooth - default is not set - bluetooth.init works in old style conditions - are based on presence hw in subsystem checked by DBus call org.freedesktop.DeviceKit.EnumerateBySubsystem Without DeviceKit ( > 002-5 ): - check_condstop() is always non-zero -> condstop doesn't work. - chech_condstart() is always 0 -> condstart do always start
Hi Bastien. We are going to test this change within Fedora Test Day [1] to find out problems you mentioned. I've prepared test case with repository [2] contains patched bluez for this purpose for F10 and rawhide based on fedora cvs sources. I'll be glad to any other suggestions according to this idea to run bluez on demand. [1] https://fedoraproject.org/wiki/QA/Test_Days/2009-04-02 [2] http://plautrba.fedorapeople.org/bluez/how-to-test.txt
How did the test day go? Do you want to get this support in bluez in devel, now that we've branched for F-11?
Test day didn't detect any problem related to ondemand service functionality and as it is disabled by default there is no risk for users who don't enable it. So we would like to add it to devel.
Could you please provide a patch against the devel branch, and request commit permissions for bluez in devel?
Created attachment 341968 [details] start,stop the bluetooth service via udev attached patch is against bluez/devel branch - 4.37-2 it provides on demand functionality based on udev events version is increased to bluez-4.37-3
Created attachment 341970 [details] start,stop the bluetooth service via udev start,stop the bluetooth service via udev attached patch is against bluez/devel branch - 4.37-2 it provides on demand functionality based on udev events version is increased to bluez-4.37-3
> + #enumarete devices Typo. Would be nice to say: "Look for Bluetooth adapters using DeviceKit" Please use tabs for indentation as done in the rest of the script. A comment though: would we want to ever have the bluetooth script started in a runlevel? (eg. is there anyway to run the script on a coldplug instead of having it start in every run-level?)
Created attachment 342337 [details] start,stop the bluetooth service via udev bluez-4.38-2 fixed typo and tab indentation
> A comment though: would we want to ever have the bluetooth script started in a > runlevel? (eg. is there anyway to run the script on a coldplug instead of > having it start in every run-level?) That is why bluetooth.init script looks for bluetooth devices also in target start (if BLUETOOTH_ONDEMAND=true is set). If it doesn't find any device, it won't start service. But we are looking for some general mechanism for "on-demand" services (probably based on something like upstart events) to avoid running needless services.
(In reply to comment #21) > > A comment though: would we want to ever have the bluetooth script started in a > > runlevel? (eg. is there anyway to run the script on a coldplug instead of > > having it start in every run-level?) > > That is why bluetooth.init script looks for bluetooth devices also in target > start (if BLUETOOTH_ONDEMAND=true is set). If it doesn't find any device, it > won't start service. > > But we are looking for some general mechanism for "on-demand" services > (probably based on something like upstart events) to avoid running needless > services. Right, so this means there's no coldplug support in udev itself. One more thing before you commit. Could you please merge check_condstop and checkcondstart? The only difference seems to be in retvals, so you could probably have a "has_bt_devices()" function as a helper.
Created attachment 342513 [details] start,stop the bluetooth service via udev bluez-4.38-3 added is_enabled_in_runlevel() and has_bt_devices() has_bt_devices() uses 'udevadm info --export-db' instead of dbus-send.
Much better (and shorter). Please commit to devel.
commited in cvs as bluez-4.38-3
Committed in the F12 branch.