Bluetoothd cannot access dbus subsytem

Burroughs · 2010-06-21 12:24:54

Hi to everyone!
I'm trying to set up my Bluetooth connection, hoping to sort something out...
Well, that's my problem, in a nutshell: everytime I connect my USB dongle to the laptop, the KBluetooth icon on the systray changes its color, showing it's ready to accept a new connection.
Once done, I try to make the laptop and the dongle pair, but there's no way, the dongle seems to be inexistent.
The reason why is explained by bluetoothd, that says, in fact:

root@andy ~]# bluetoothd -d -n
bluetoothd[19611]: Bluetooth deamon 4.65
bluetoothd[19611]: src/main.c:parse_config() parsing main.conf
bluetoothd[19611]: src/main.c:parse_config() discovto=0
bluetoothd[19611]: src/main.c:parse_config() pairto=0
bluetoothd[19611]: src/main.c:parse_config() pageto=8192
bluetoothd[19611]: src/main.c:parse_config() name=archy
bluetoothd[19611]: src/main.c:parse_config() class=0x000100
bluetoothd[19611]: src/main.c:parse_config() discov_interval=0
bluetoothd[19611]: src/main.c:parse_config() deviceid=0022:FD43:58BA
bluetoothd[19611]: Unable to get on D-Bus

Thinking it was a permission problem, I put my user in the lp group, that can access, by default, the Bluetooth service:

[root@andy system.d]# grep -i 'lp' bluetooth.conf 
  <!-- allow users of lp group (printing subsystem) to 
  <policy group="lp">

Once restarting the daemon, though, I notice nothing changes.
I'll give you more technical info: I'm a using a Nokia N95 8GB cell phone, my Bluetooth USB dongle is a Broadcom one, regularly detected by the kernel:

Bus 006 Device 002: ID 0a5c:2035 Broadcom Corp. BCM2035 Bluetooth

this is my /etc/bluetooth/rfcomm.conf file:

[root@andy ~]# cat /etc/bluetooth/rfcomm.conf 
# RFCOMM configuration file.
#

#rfcomm0 {
#       # Automatically bind the device at startup
#       bind no;
#
#       # Bluetooth address of the device
        device XX:XX:XX:XX:XX:XX;
#
#       # RFCOMM channel for the connection
        channel 4;
#
#       # Description of the connection
#       comment "Example Bluetooth device";
#}

this is my /etc/bluetooth/main.conf one:

[root@andy ~]# cat /etc/bluetooth/main.conf   
[General]

# List of plugins that should not be loaded on bluetoothd startup
#DisablePlugins = network,input

# Default adaper name
# %h - substituted for hostname
# %d - substituted for adapter id
Name = archy

# Default device class. Only the major and minor device class bits are
# considered.
Class = 0x000100

# How long to stay in discoverable mode before going back to non-discoverable
# The value is in seconds. Default is 180, i.e. 3 minutes.
# 0 = disable timer, i.e. stay discoverable forever
DiscoverableTimeout = 0

# How long to stay in pairable mode before going back to non-discoverable
# The value is in seconds. Default is 0.
# 0 = disable timer, i.e. stay pairable forever
PairableTimeout = 0

# Use some other page timeout than the controller default one
# which is 16384 (10 seconds).
PageTimeout = 8192

# Discover scheduler interval used in Adapter.DiscoverDevices
# The value is in seconds. Defaults is 0 to use controller scheduler.
DiscoverSchedulerInterval = 0

# What value should be assumed for the adapter Powered property when
# SetProperty(Powered, ...) hasn't been called yet. Defaults to true
InitiallyPowered = true

# Remember the previously stored Powered state when initializing adapters
RememberPowered = true

# Use vendor, product and version information for DID profile support.
# The values are separated by ":" and VID, PID and version.
DeviceID = XXXX:XXXX:XXXX

# Do reverse service discovery for previously unknown devices that connect to
# us. This option is really only needed for qualification since the BITE tester
# doesn't like us doing reverse SDP for some test cases (though there could in
# theory be other useful purposes for this too). Defaults to true.
ReverseServiceDiscovery = true

# Enable name resolving after inquiry. Set it to 'false' if you don't need
# remote devices name and want shorter discovery cycle. Defaults to 'true'.
NameResolving = true

and, last but not least, my /etc/conf.d/bluetooth one:

[root@andy ~]# cat /etc/conf.d/bluetooth 
# Bluetooth configuraton file

# Bluetooth services (allowed values are "true" and "false")

# Run the bluetoothd daemon (default: true)
DAEMON_ENABLE="false"

# Run hid2hci (default: false)
HID2HCI_ENABLE="true"

# Run the sdp daemon (default: false)
# If this is disabled, hcid's internal sdp daemon will be used
SDPD_ENABLE="true"

# Run the bluetooth HID daemon (default: false)
HIDD_ENABLE="true"

# Activate rfcomm ports (default: false)
#RFCOMM_ENABLE="true"

# Run bluetooth dial-up networking daemon (default: false)
#DUND_ENABLE="true"

# Run bluetooth PAN daemon (default: false)
#PAND_ENABLE="true"

# rfcomm configuration file (default: /etc/bluetooth/rfcomm.conf)
RFCOMM_CONFIG="/etc/bluetooth/rfcomm.conf"

# Options for hidd, dund and pand (default: none)
#HIDD_OPTIONS=""
#DUND_OPTIONS=""
#PAND_OPTIONS=""

Any further help would be greatly appreciated.

Burroughs.

Last edited by Burroughs (2010-06-21 12:26:58)

Mr.Elendig · 2010-06-21 12:50:07

Is dbus actually running?
Are you running a consolekit session?

Burroughs · 2010-06-21 13:13:16

Mr.Elendig wrote:

Is dbus actually running?
Are you running a consolekit session?

Yes, dbus is running and has been added to the /etc/rc.conf file:

[root@andy ~]# grep -i 'dbus' /etc/rc.conf 
DAEMONS=(syslog-ng iptables network netfs crond dbus hal bluetooth wicd ntpd sshd mysqld clamav spamd)

Burroughs.

Mr.Elendig · 2010-06-21 13:44:50

and are you running a consolekit session?

Burroughs · 2010-06-21 13:46:56

Mr.Elendig wrote:

and are you running a consolekit session?

Don't know what it is...
Can you explain?

Burroughs.

fearthewildllama · 2011-01-12 20:33:37

So, I'm not sure if you're still having a problem or not... but it may be the way that d-bus communicates on your system...

Inside of src/main.c for bluetoothd, change this line

conn = g_ dbus_ setup_bus(DBUS_BUS_SYSTEM, BLUEZ_NAME, &err);
To
conn = g_ dbus_ setup_bus(DBUS_BUS_SESSION, BLUEZ_NAME, &err);

This will avoid use of /var/run/dbus/system_bus_socket (I'm guessing this doesn't exist on your system).

ngoonee · 2011-01-12 22:47:48

fearthewildllama wrote:

So, I'm not sure if you're still having a problem or not... but it may be the way that d-bus communicates on your system...
Inside of src/main.c for bluetoothd, change this line
conn = g_ dbus_ setup_bus(DBUS_BUS_SYSTEM, BLUEZ_NAME, &err);
To
conn = g_ dbus_ setup_bus(DBUS_BUS_SESSION, BLUEZ_NAME, &err);
This will avoid use of /var/run/dbus/system_bus_socket (I'm guessing this doesn't exist on your system).

Seriously, you'd patch source for this? Most likely the OP is simply not running console-kit and thus doesn't have the permissions necessary. Or other permissions issue. That "solution" is simply a hack, and shouldn't generally be used.

quaec · 2011-02-06 18:43:24

Hi!

I've got the exact same problem with an up-to-date arch linux installation. Consolekit is installed. Do I have to configure it in some way?
DBus and bluetooth(d) are installed and are in the "DEAMONS=()" section of the rc.d configuration file.

Thanks!

Arch Linux

#1 2010-06-21 12:24:54

Bluetoothd cannot access dbus subsytem

#2 2010-06-21 12:50:07

Re: Bluetoothd cannot access dbus subsytem

#3 2010-06-21 13:13:16

Re: Bluetoothd cannot access dbus subsytem

#4 2010-06-21 13:44:50

Re: Bluetoothd cannot access dbus subsytem

#5 2010-06-21 13:46:56

Re: Bluetoothd cannot access dbus subsytem

#6 2011-01-12 20:33:37

Re: Bluetoothd cannot access dbus subsytem

#7 2011-01-12 22:47:48

Re: Bluetoothd cannot access dbus subsytem

#8 2011-02-06 18:43:24

Re: Bluetoothd cannot access dbus subsytem

Board footer