Bug 484345

Summary: start the bluetooth service via udev
Product: [Fedora] Fedora Reporter: Adel Gadllah <adel.gadllah>
Component: bluezAssignee: Bastien Nocera <bnocera>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: amlau, bnocera, dwmw2, harald, marcel, michael.monreal+bugs, mmaslano, plautrba, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-06 10:18:15 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 484668    
Attachments:
Description Flags
udev rule
none
shell script to be placed in /lib/udev
none
start and stop service on demand based on udev events
none
start,stop the bluetooth service via udev
none
start,stop the bluetooth service via udev
none
start,stop the bluetooth service via udev
none
start,stop the bluetooth service via udev none

Description Adel Gadllah 2009-02-06 05:37:49 EST
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.
Comment 1 Adel Gadllah 2009-02-06 05:38:42 EST
Created attachment 331114 [details]
shell script to be placed in /lib/udev
Comment 2 Harald Hoyer 2009-02-09 07:37:36 EST
ping?
Comment 3 Bastien Nocera 2009-02-09 07:55:28 EST
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.
Comment 4 David Woodhouse 2009-02-10 06:04:54 EST
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.
Comment 5 Harald Hoyer 2009-02-10 06:11:45 EST
This looks like we have to define a mechanism which depends on hardware presence and runlevel configuration for service actions.
Comment 6 Bastien Nocera 2009-02-10 06:37:48 EST
(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.
Comment 7 David Woodhouse 2009-02-10 06:38:42 EST
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.
Comment 8 Radek Vokal 2009-03-02 11:40:02 EST
My 2 cents, have you guys seen work done by Petr Lautrbach .. https://bugzilla.redhat.com/show_bug.cgi?id=487665
Comment 9 Bastien Nocera 2009-03-02 20:50:07 EST
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.
Comment 10 Petr Lautrbach 2009-03-06 05:17:34 EST
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
Comment 11 Petr Lautrbach 2009-03-06 06:03:15 EST
src.rpm: http://plautrba.fedorapeople.org/bluez/bluez-4.32-1.1.fc10.src.rpm
Comment 12 Petr Lautrbach 2009-03-09 10:57:01 EDT
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
Comment 13 Petr Lautrbach 2009-03-23 05:09:43 EDT
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
Comment 14 Bastien Nocera 2009-04-23 13:24:30 EDT
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?
Comment 15 Petr Lautrbach 2009-04-28 02:52:42 EDT
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.
Comment 16 Bastien Nocera 2009-04-28 05:47:51 EDT
Could you please provide a patch against the devel branch, and request commit permissions for bluez in devel?
Comment 17 Petr Lautrbach 2009-04-30 13:30:06 EDT
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
Comment 18 Petr Lautrbach 2009-04-30 13:36:27 EDT
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
Comment 19 Bastien Nocera 2009-05-02 19:21:07 EDT
> +  #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?)
Comment 20 Petr Lautrbach 2009-05-04 12:47:54 EDT
Created attachment 342337 [details]
start,stop the bluetooth service via udev   

bluez-4.38-2

fixed typo and tab indentation
Comment 21 Petr Lautrbach 2009-05-05 03:04:12 EDT
> 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.
Comment 22 Bastien Nocera 2009-05-05 05:49:26 EDT
(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.
Comment 23 Petr Lautrbach 2009-05-05 14:19:23 EDT
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.
Comment 24 Bastien Nocera 2009-05-06 06:11:41 EDT
Much better (and shorter). Please commit to devel.
Comment 25 Petr Lautrbach 2009-05-06 07:49:36 EDT
commited in cvs as bluez-4.38-3
Comment 26 Bastien Nocera 2009-05-06 10:18:15 EDT
Committed in the F12 branch.