Bug 3655 - bluetooth device activation issue
Summary: bluetooth device activation issue
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: D Morgan
QA Contact:
URL:
Whiteboard:
Keywords: Triaged
Depends on:
Blocks:
 
Reported: 2011-12-07 10:22 CET by Guillaume Rousse
Modified: 2011-12-22 10:13 CET (History)
1 user (show)

See Also:
Source RPM: bluez
CVE:
Status comment:


Attachments

Description Guillaume Rousse 2011-12-07 10:22:57 CET
With the current bluez package, the udev rules responsible for the creation of the bluetooth device apparently never fire, under systemd, at least. The upstream rules are:

ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="@prefix@/sbin/bluetoothd --udev"
ACTION=="change", SUBSYSTEM=="bluetooth", RUN+="@prefix@/sbin/bluetoothd --udev"

They have been patched in mandriva by A. Borzenkov this way, which apparently make them unused when systemd is used, and also ensure the action is retried later when an error occurs:

TEST{040000}!="/sys/fs/cgroup/systemd", ACTION=="add", SUBSYSTEM=="bluetooth", RUN{fail_event_on_error}+="@prefix@/sbin/bluetoothd --udev"
TEST{040000}!="/sys/fs/cgroup/systemd", ACTION=="change", SUBSYSTEM=="bluetooth", RUN+="@prefix@/sbin/bluetoothd --udev"

In the current fedora package, this patch doesn't exist, but another one is also applied, which install an additional dbus configuration file:
http://pkgs.fedoraproject.org/gitweb/?p=bluez.git;a=blob_plain;f=0001-systemd-install-systemd-unit-files.patch;hb=HEAD

As dbus is refered to in the systemd service file, I guess this patch is actually needed to have bluetooth working with systemd, whereas our own one is discussable. The "do not fire under systemd" part is apparently useless (fedora don't need it, whereas they are systemd only), but the fail_event_on_error attribute may be needed. When testing with only the fedora part applied, the device is not created during startup, I have to turn the hardware switch off and on again to fire the rule.
Comment 1 Manuel Hiebel 2011-12-07 11:48:58 CET
Hi, thanks for reporting this bug.
Assigned to the package maintainer.

Keywords: (none) => Triaged
Assignee: bugsquad => dmorganec

Comment 2 Guillaume Rousse 2011-12-18 19:28:51 CET
The latest package seems better, but there is still an issue at boot time:
Dec 18 19:20:39 localhost dbus[1881]: [system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service'
Dec 18 19:20:39 localhost dbus-daemon[1881]: dbus[1881]: [system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service'
Dec 18 19:20:39 localhost dbus[1881]: [system] Activation via systemd failed for unit 'dbus-org.bluez.service': Unit dbus-org.bluez.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.bluez.service' for details.
Dec 18 19:20:39 localhost dbus-daemon[1881]: dbus[1881]: [system] Activation via systemd failed for unit 'dbus-org.bluez.service': Unit dbus-org.bluez.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.bluez.service' for details.

BTW, each line seems to be logged twice, with different process identifier (dbus[1881] vs dbus-daemon[1881]: dbus[1881]), but that's a minor issue.

'systemctl start bluetooth.service' is enough to make it works, after boot is finished. My /usr tree is not a different partition.
Comment 3 Colin Guthrie 2011-12-18 21:44:56 CET
You should just be able to do: systemctl enable bluetooth.service and all should be well.

Can you confirm?

CC: (none) => mageia

Comment 4 Guillaume Rousse 2011-12-22 10:13:14 CET
Indeed, I was confused by the 'dead' word in systemctl status output. Everything works OK now.

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.