Bug 708572

systemd's looking for "dbus-org.bluez.service", but bluez-4.86-5.fc15.i686 drops "org.bluez.service" into /usr/share/dbus-1/system-services directory. 

I changed the alias in /lib/systemd/system/bluetooth.service to "org.bluez.service" and `systemctl start bluetooth.service` worked. That shouldn't be necessary (it's in /lib, not /etc).

Additionally, Gnome3 unhelpfully only shows "Bluetooth is disabled" instead of indicating something about how the bluez service fails to start, but that's probably another bug.

Er, that should be bluez-4.87-5, not .86

Ok i have changed the alias so hopefully the lockups will stop occuring now thankyou james.If this solves the problem. What do i do next, ,do i close the bug report?

Created attachment 502769 [details]
/var/log/messages

Changing the alias hasn't solved the problem.I have attached my messages log.There is still something looking for dbus-org-bluez service.Can anyone give me help on any other logs to check as it still crashes constantly.

My problem may be a duplicate of this bug https://bugzilla.redhat.com/show_bug.cgi?id=697157

The lockups certainly have nothing to do with bluez. Especially if bluez isn't running.

on my Asus 12xx
http://www.smolts.org/client/show/pub_e9f34fbb-dd9d-4b7d-8c77-027292c81297

I have resolve with this command ;
# systemctl enable bluetooth.service
# systemctl start dbus-org.bluez.service

Now bluetooth work.

(In reply to comment #8)
> on my Asus 12xx
> http://www.smolts.org/client/show/pub_e9f34fbb-dd9d-4b7d-8c77-027292c81297
> 
> I have resolve with this command ;
> # systemctl enable bluetooth.service
> # systemctl start dbus-org.bluez.service
> 
> Now bluetooth work.

Worked also for me.

Fedora 16 x86_64.

While this bug doesn't "lock my GNOME session", it causes a boot delay for some 20 seconds and neither of the above mentioned methods does help it either. 
The command `systemctl start dbus-org.bluez.service` causes error:"file not found" regardless of whether or not I enable the bluetooth.service or change names in that file.

Regards,
Kostya

http://www.smolts.org/client/show/?uuid=pub_d71dc9ab-d675-4ee2-a9a9-303efc25df83

http://www.toshibadirect.com/td/b2c/retail-product.jsp?poid=431238
"Bluetooth: No Bluetooth (No Antenna)"

get error on fc17beta:

# systemctl status bluetooth.service
bluetooth.service - Bluetooth Manager
	  Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled)
	  Active: inactive (dead)
	  CGroup: name=systemd:/system/bluetooth.service

# systemctl status dbus-org.bluez.service
dbus-org.bluez.service
	  Loaded: error (Reason: No such file or directory)
	  Active: inactive (dead)

# systemctl start dbus-org.bluez.service
Failed to issue method call: 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.
# 

dbus-1:1.4.10-4.fc17.x86_64

Is this still happening on any particular release?

see smolt in comment#11
(not even sure if machine 'officially' has bluetooth 
but then should error accordingly instead of die anyhow)

on fc16 with:

  kernel-3.3.7-1.fc16.x86_64
  dbus-1:1.4.10-3.fc16.x86_64
  bluez-4.96-3.fc16.x86_64

messages:
dbus-daemon[1040]: dbus[1040]: [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.

$ systemctl status bluetooth.service
bluetooth.service - Bluetooth service
	  Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled)
	  Active: inactive (dead)
	  CGroup: name=systemd:/system/bluetooth.service

$ systemctl status dbus-org.bluez.service
dbus-org.bluez.service
	  Loaded: error (Reason: No such file or directory)
	  Active: inactive (dead)


similar response on fc17 with:

  kernel-3.4.0-1.fc17.x86_64 
  dbus-1:1.4.10-4.fc17.x86_64
  bluez-4.99-1.fc17.x86_64

will attach messages from fc17 instance

Created attachment 589985 [details]
var log messages from fc17 for bluez dbus

Created attachment 592351 [details]
excerp from /var/log/messages

I am not using gnome but this is the closest I've found in relation to the error i am getting from bluetoothd.

I think the key lines may be these:
***begin***
...
Jun 16 15:43:51 david bluetoothd[4896]: Bluetooth daemon 4.99
Jun 16 15:43:51 david bluetoothd[4896]: Unable to get on D-Bus
Jun 16 15:43:51 david bluetoothd[4896]: D-Bus setup failed: Name already in use
Jun 16 15:43:51 david bluetoothd[4896]: bluetoothd[4896]: Unable to get on D-Bus
Jun 16 15:43:51 david systemd[1]: bluetooth.service: main process exited, code=exited, status=1
Jun 16 15:43:51 david systemd[1]: Unit bluetooth.service entered failed state.
...
***end***

See the attachment for the full excerpt of /var/log/messages showing what happens when I replug (unplug, wait a sec, plug) my bluetooth usb device and then turning my bluetooth headset (ad2p) on.

I don't see anything in any of these reports that indicate a kernel bug.
We fixed a number of bluetooth related kernel oopses a while ago, but there shouldn't be anything outstanding that would explain why dbus would crap itself.

for me, the problem is bluez-4.96.3 (fc16)

In bluez-4.99.2 (fc17) the problem is apparently fixed.  Applying this patch to fc16's /lib/systemd/system/bluetooth.service is a fix for me:

--- a/bluetooth.service   2012-12-17 14:11:16 -0600
+++ b/bluetooth.service   2012-12-17 14:12:03 -0600
@@ -10,3 +1-,4 @@

 [Install]
 WantedBy=bluetooth.target
+Alias=dbus-org.bluez.service

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.