15:10 and 16.04: bluetoothd "Failed to start discovery: org.bluez.Error.NotReady" after bluetoothd restarted

Bug #1490349 reported by TJ on 2015-08-30
608
This bug affects 134 people
Affects Status Importance Assigned to Milestone
bluez (Ubuntu)
High
Unassigned

Bug Description

On 15:10 after the bluetooth service has been stopped and restarted it is not possible to scan or connect to devices:

$ sudo systemctl restart bluetooth

$ bluetoothctl
[NEW] Controller 00:1F:3A:E0:0A:AF hephaestion.lan.iam.tj [default]
[NEW] Device 00:0A:95:4B:BD:C2 Apple Wireless Keyboard
[NEW] Device 00:07:61:3B:86:98 Bluetooth Travel Mouse
[bluetooth]# scan on
Failed to start discovery: org.bluez.Error.NotReady

TJ (tj) wrote :

This also occurs from a fresh boot:

Aug 30 23:42:21 hephaestion.lan.iam.tj systemd[1]: Starting Bluetooth service...
Aug 30 23:42:21 hephaestion.lan.iam.tj bluetoothd[793]: Bluetooth daemon 5.33
Aug 30 23:42:21 hephaestion.lan.iam.tj bluetoothd[793]: Starting SDP server
Aug 30 23:42:21 hephaestion.lan.iam.tj bluetoothd[793]: Bluetooth management interface 1.9 initialized
Aug 30 23:42:21 hephaestion.lan.iam.tj systemd[1]: Started Bluetooth service.
Aug 30 23:42:21 hephaestion.lan.iam.tj bluetoothd[793]: Failed to obtain handles for "Service Changed" characteristic
Aug 30 23:42:21 hephaestion.lan.iam.tj bluetoothd[793]: Not enough free handles to register service
Aug 30 23:42:21 hephaestion.lan.iam.tj bluetoothd[793]: Error adding Link Loss service
Aug 30 23:42:21 hephaestion.lan.iam.tj bluetoothd[793]: Not enough free handles to register service
Aug 30 23:42:21 hephaestion.lan.iam.tj bluetoothd[793]: Not enough free handles to register service
Aug 30 23:42:21 hephaestion.lan.iam.tj bluetoothd[793]: Not enough free handles to register service
Aug 30 23:42:21 hephaestion.lan.iam.tj bluetoothd[793]: Current Time Service could not be registered
Aug 30 23:42:21 hephaestion.lan.iam.tj bluetoothd[793]: gatt-time-server: Input/output error (5)
Aug 30 23:42:21 hephaestion.lan.iam.tj bluetoothd[793]: Not enough free handles to register service
Aug 30 23:42:21 hephaestion.lan.iam.tj bluetoothd[793]: Not enough free handles to register service
Aug 30 23:42:21 hephaestion.lan.iam.tj bluetoothd[793]: Sap driver initialization failed.
Aug 30 23:42:21 hephaestion.lan.iam.tj bluetoothd[793]: sap-server: Operation not permitted (1)
Aug 30 23:42:25 hephaestion.lan.iam.tj bluetoothd[793]: Endpoint registered: sender=:1.33 path=/MediaEndpoint/A2DPSource
Aug 30 23:42:25 hephaestion.lan.iam.tj bluetoothd[793]: Endpoint registered: sender=:1.33 path=/MediaEndpoint/A2DPSink
Aug 30 23:43:06 hephaestion.lan.iam.tj bluetoothd[793]: Endpoint registered: sender=:1.68 path=/MediaEndpoint/A2DPSource
Aug 30 23:43:06 hephaestion.lan.iam.tj bluetoothd[793]: Endpoint registered: sender=:1.68 path=/MediaEndpoint/A2DPSink
Aug 30 23:43:06 hephaestion.lan.iam.tj bluetoothd[793]: RFCOMM server failed for Headset Voice gateway: rfcomm_bind: Address already in use (98)
Aug 30 23:43:15 hephaestion.lan.iam.tj bluetoothd[793]: Endpoint unregistered: sender=:1.33 path=/MediaEndpoint/A2DPSource
Aug 30 23:43:15 hephaestion.lan.iam.tj bluetoothd[793]: Endpoint unregistered: sender=:1.33 path=/MediaEndpoint/A2DPSink

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in bluez (Ubuntu):
status: New → Confirmed
Simon Fels (morphis) wrote :

This pretty much looks like the adapter is just not automatically enabled again after you restart the service. There is currently a udev workaround rule in place to active a Bluetooth adapter directly at login-screen time which wouldn't kick in here again. If there is no general power state saver on desktop like urfkill you have to manually enable bluetooth again.

Hibernator (psychotux) wrote :

#3 seems to be correct.

I added the following lines to the end of /etc/pulse/system.pa:

<BEGIN of snippet>
### Automatically load driver modules for Bluetooth hardware
.ifexists module-bluetooth-policy.so
load-module module-bluetooth-policy
.endif

.ifexists module-bluetooth-discover.so
load-module module-bluetooth-discover
.endif
<END of snippet>

(Notice: I stole the snippet above from this informative page: https://github.com/ev3dev/ev3dev/issues/198 )

After executing pulseaudio -k all went smooth, bluetooth headphone seems to work well for now. Hope it will stay that way.

znorris (znorris) wrote :

Thank you for mentioning that you can manually add the device. My mouse wasn't paired even using the hardware buttons. Going to the bluetooth manager and selecting the mouse did work. I've added the udev rules in the hope I won't need to do this manually each time. Thank you.

do we have any follow up on this bug? needs more info?

jbMacAZ (jbmacbrodie) wrote :

I have these errors in my dmesg with kernel 4.5.0 but not in 4.3.6 where bluetooth works great. Kernel 4.4.x bluetooth behaves the same as 4.5.0 but I hadn't noticed if there are "failed to obtain..." messages.

When I boot in 4.3.6 bluetooth (bluez 5.35 and blueman, and a command btattach... in /etc/rc.local) starts fine and I don't have to do much to wake-up my bluetooth mouse and keyboard. In 4.4+ I have to manually search for the devices, but I don't have to pair them again. I then have to leave the blueman device manager running (minimized.) If anything times out from inactivity, I have to search again to reconnect.

Asus T100-CHI Ubuntu 15.10-i386. Minimally patch kernel supports a lot of the hardware of the T100, except sound, cameras, mic... Bluetooth started working in kernel 4.3.3+ but regressed starting with 4.4-rc1->4.5.0.

I see a reference to a udev workaround, but that is a new area to me. The example seems aimed at audio - how would I adapt that to mouse/keyboard?

jbMacAZ (jbmacbrodie) wrote :

2 updates: 4.5.0-next-20160321: bluetooth self-starts like 4.3.6 used to. I still need to open device manager to maintain connections, but I no longer have to manually search for already paired devices.

The "failed to obtain..." messages are in journalctl not dmesg. Sorry for any confusion that may have caused.

Brian Burch (brian-pingtoo) wrote :

Same messages for me with 16.04 beta2, running with bluez 5.37-0ubuntu5 on 4.4.0-15-generic amd64 kernel. Running on Asus T300 CHI notepad with bluetooth keyboard/touchpad docking unit. It pairs OK, but connection comes up briefly and then drops again.

bluetoothctl log extract follows:
[CHG] Device 08:62:66:DB:F3:AA Paired: yes
Pairing successful
[CHG] Device 08:62:66:DB:F3:AA Connected: no
[CHG] Device 08:62:66:DB:F3:AA Class: 0x0005c0
[CHG] Device 08:62:66:DB:F3:AA Connected: yes
[CHG] Device 08:62:66:DB:F3:AA Icon is nil

jbMacAZ (jbmacbrodie) wrote :

@Brian Burch - You might get more run time if you minimize the bt device manager window instead of closing it after pairing (assuming that you are using blueman device manager.) I find kernel 4.5 works a little bit better with bluetooth. kernel 4.3.6 works like I'd expect with bluetooth, if you don't need the newer kernel features.

We are describing is a kernel bug. I have the same bt connectivity issues using Manjaro.

Brian Burch (brian-pingtoo) wrote :

Following a suggestion from jbmacbrodie to minimise the blueman device manager after pairing, I tried again. This time, I used the command-line bluetoothctl program as sudo: the "paired-devices" command showed the device was already paired from my previous session. "info [mac addr]" showed it was not legacy-paired and not currently connected.

I flicked the switch on the docking unit (a bluetooth keyboard with touchpad) so it would try to establish a connection. I then issued the "connect [mac addr]", and bluetoothctl briefly showed it was connected and the blue LED on the keyboard changed from blinking, to solid on, then back to solid off in a matter of a few seconds.

syslog showed:

Apr 8 15:28:39 Muscat bluetoothd[610]: Can't get HIDP connection info
Apr 8 15:28:40 Muscat kernel: [ 1066.735075] hid-generic 0005:0B05:8502.0004: unknown main item tag 0x0
Apr 8 15:28:40 Muscat kernel: [ 1066.735354] input: ASUS T300CHI DOCKING as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:256/0005:0B05:8502.0004/input/input16
Apr 8 15:28:40 Muscat kernel: [ 1066.735950] hid-generic 0005:0B05:8502.0004: input,hidraw3: BLUETOOTH HID v0.01 Keyboard [ASUS T300CHI DOCKING] on 60:57:18:59:0a:64
Apr 8 15:28:40 Muscat bluetoothd[610]: No agent available for request type 0
Apr 8 15:28:40 Muscat bluetoothd[610]: device_request_pin: Operation not permitted

I had just rebooted the latest (4.4.0-17-generic) kernel and bluetoothd logged the "not enough handles" message again when starting. I don't know whether this is a symptom of the kernel bug, or something completely different!

This bug still exists in xenial with kernel 4.5:

$ uname -a
Linux xeelee 4.5.0-040500-lowlatency #201603140130 SMP PREEMPT Mon Mar 14 05:37:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

$ journalctl |grep bluetoothd
Apr 08 20:24:43 xeelee bluetoothd[929]: Bluetooth daemon 5.37
Apr 08 20:24:43 xeelee bluetoothd[929]: Starting SDP server
Apr 08 20:24:43 xeelee bluetoothd[929]: Bluetooth management interface 1.11 initialized
Apr 08 20:24:43 xeelee bluetoothd[929]: Failed to obtain handles for "Service Changed" characteristic
Apr 08 20:24:43 xeelee bluetoothd[929]: Not enough free handles to register service
Apr 08 20:24:43 xeelee bluetoothd[929]: Error adding Link Loss service
Apr 08 20:24:43 xeelee bluetoothd[929]: Not enough free handles to register service
Apr 08 20:24:43 xeelee bluetoothd[929]: Not enough free handles to register service
Apr 08 20:24:43 xeelee bluetoothd[929]: Not enough free handles to register service
Apr 08 20:24:43 xeelee bluetoothd[929]: Current Time Service could not be registered
Apr 08 20:24:43 xeelee bluetoothd[929]: gatt-time-server: Input/output error (5)
Apr 08 20:24:43 xeelee bluetoothd[929]: Not enough free handles to register service
Apr 08 20:24:43 xeelee bluetoothd[929]: Not enough free handles to register service
Apr 08 20:24:43 xeelee bluetoothd[929]: Sap driver initialization failed.
Apr 08 20:24:43 xeelee bluetoothd[929]: sap-server: Operation not permitted (1)
Apr 08 20:24:55 xeelee bluetoothd[929]: Endpoint registered: sender=:1.41 path=/MediaEndpoint/A2DPSource
Apr 08 20:24:55 xeelee bluetoothd[929]: Endpoint registered: sender=:1.41 path=/MediaEndpoint/A2DPSink

Brian Burch (brian-pingtoo) wrote :

Following a suggestion from jbmacbrodie to minimise the blueman device manager after pairing, I tried again. This time, I used the command-line bluetoothctl program as sudo: the "paired-devices" command showed the device was already paired from my previous session. "info [mac addr]" showed it was not legacy-paired and not currently connected.

I flicked the switch on the docking unit (a bluetooth keyboard with touchpad) so it would try to establish a connection. I then issued the "connect [mac addr]", and bluetoothctl briefly showed it was connected and the blue LED on the keyboard changed from blinking, to solid on, then back to solid off in a matter of a few seconds.

syslog showed:

Apr 8 15:28:39 Muscat bluetoothd[610]: Can't get HIDP connection info
Apr 8 15:28:40 Muscat kernel: [ 1066.735075] hid-generic 0005:0B05:8502.0004: unknown main item tag 0x0
Apr 8 15:28:40 Muscat kernel: [ 1066.735354] input: ASUS T300CHI DOCKING as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:256/0005:0B05:8502.0004/input/input16
Apr 8 15:28:40 Muscat kernel: [ 1066.735950] hid-generic 0005:0B05:8502.0004: input,hidraw3: BLUETOOTH HID v0.01 Keyboard [ASUS T300CHI DOCKING] on 60:57:18:59:0a:64
Apr 8 15:28:40 Muscat bluetoothd[610]: No agent available for request type 0
Apr 8 15:28:40 Muscat bluetoothd[610]: device_request_pin: Operation not permitted

I had just rebooted the latest (4.4.0-17-generic) kernel and bluetoothd logged the "not enough handles" message again when starting. I don't know whether this is a symptom of the kernel bug, or something completely different!

Brian Burch (brian-pingtoo) wrote :

I also true using an old bluetooth usb dongle. I used it on the asus T300, but that made no difference. I also tried it on my dell 1558 laptop, with 16.04 (64-bit) and 15.10 (32-bit with bluez 5.35). The 16.04 test was basically the same as on the asus. The 15.10 test was different in detail, but still showed the docking station briefly connecting, but disconnecting a second or so later.

All tests produced the "not enough handles" message from bluetoothd. Is anyone successfully using bluetooth with these later ubuntu kernels?

> All tests produced the "not enough handles" message from bluetoothd.
> Is anyone successfully using bluetooth with these later ubuntu kernels?

On both of my systems I get the "not enough handles" messages but I got BT to work for both my use cases:
 - using a BT mouse on a laptop
 - streaming audio from my phone to my HTPC

On 15/04/16 03:19, Laurent Bonnaud wrote:
>> All tests produced the "not enough handles" message from bluetoothd.
>> Is anyone successfully using bluetooth with these later ubuntu kernels?
>
> On both of my systems I get the "not enough handles" messages but I got BT to work for both my use cases:
> - using a BT mouse on a laptop
> - streaming audio from my phone to my HTPC

That is useful to know, Laurent. I am pleased to know it works somewhere!

I successfully paired my android phone to the T300, so this shows the
hardware and software is capable of recognising and using the "just
works" agent for a Simple Simple Pairing exchange (i.e. without
requiring user entry of a pin). I can't be sure, but I think this is
what happened when I paired the keyboard with windows 10.

Incidentally, I just tried connecting my wife's phone, which is newer
but almost identical. It paired but would not connect. I will run some
more btmon traces later today to look for significant differences.

I have a possible variant of this bug in 16.10 with a 4.4.0-22 (standard kernel at time of writing), after a day or so of uptime i start to get these messages. they seem to go away after a log out and login.

This is on a dell precision m3800 using plantronic back beat pro headphones , this combination worked semi flawlessly for the duration of 15.10 and most of 15.04.

this seemed to help, now my headset auto connects on startup
http://askubuntu.com/questions/689281/pulseaudio-can-not-load-bluetooth-module-15-10-16-04

maarten derksen (derxen) wrote :

I have this bug too, on 16.04. After booting bluetooth works fine, then after suspend it's gone, and I get the 'not enough handles' errors. Only rebooting works. The solution of amias does not work for me.

maarten derksen (derxen) wrote :

I switched to Gnome, where I do not have this problem. Apparently it has something to do with Unity.

maarten derksen (derxen) wrote :

Sorry, I was wrong, the problem occurs in Gnome as well, but not every time.

zhang sheng (langyxxl) wrote :

I use ubuntu16.04, my computer can't connect to my bluetooth speaker after reboot.

uname -a
Linux zs-PC 4.4.0-24-generic #43-Ubuntu SMP Wed Jun 8 19:27:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

journalctl --unit=bluetooth
-- Logs begin at 一 2016-06-20 18:41:21 CST, end at 一 2016-06-20 18:43:45 CST. --
6月 20 18:41:36 zs-PC systemd[1]: Starting Bluetooth service...
6月 20 18:41:36 zs-PC bluetoothd[818]: Bluetooth daemon 5.37
6月 20 18:41:36 zs-PC systemd[1]: Started Bluetooth service.
6月 20 18:41:36 zs-PC bluetoothd[818]: Starting SDP server
6月 20 18:41:36 zs-PC bluetoothd[818]: Bluetooth management interface 1.10 initialized
6月 20 18:41:36 zs-PC bluetoothd[818]: Failed to obtain handles for "Service Changed" characteristic
6月 20 18:41:36 zs-PC bluetoothd[818]: Not enough free handles to register service
6月 20 18:41:36 zs-PC bluetoothd[818]: Error adding Link Loss service
6月 20 18:41:36 zs-PC bluetoothd[818]: Not enough free handles to register service
6月 20 18:41:36 zs-PC bluetoothd[818]: Not enough free handles to register service
6月 20 18:41:36 zs-PC bluetoothd[818]: Not enough free handles to register service
6月 20 18:41:36 zs-PC bluetoothd[818]: Current Time Service could not be registered
6月 20 18:41:36 zs-PC bluetoothd[818]: gatt-time-server: Input/output error (5)
6月 20 18:41:36 zs-PC bluetoothd[818]: Not enough free handles to register service
6月 20 18:41:36 zs-PC bluetoothd[818]: Not enough free handles to register service
6月 20 18:41:36 zs-PC bluetoothd[818]: Sap driver initialization failed.
6月 20 18:41:36 zs-PC bluetoothd[818]: sap-server: Operation not permitted (1)
6月 20 18:41:48 zs-PC bluetoothd[818]: Endpoint registered: sender=:1.43 path=/MediaEndpoint/A2DPSource
6月 20 18:41:48 zs-PC bluetoothd[818]: Endpoint registered: sender=:1.43 path=/MediaEndpoint/A2DPSink
6月 20 18:41:53 zs-PC bluetoothd[818]: Endpoint registered: sender=:1.67 path=/MediaEndpoint/A2DPSource
6月 20 18:41:53 zs-PC bluetoothd[818]: Endpoint registered: sender=:1.67 path=/MediaEndpoint/A2DPSink
6月 20 18:41:53 zs-PC bluetoothd[818]: RFCOMM server failed for Headset Voice gateway: rfcomm_bind: Address already in use (98)
6月 20 18:42:10 zs-PC bluetoothd[818]: Endpoint unregistered: sender=:1.43 path=/MediaEndpoint/A2DPSource
6月 20 18:42:10 zs-PC bluetoothd[818]: Endpoint unregistered: sender=:1.43 path=/MediaEndpoint/A2DPSink

From now, I can only use my bluetooth speaker by:
1. delete it from the bluetooth device list
2. research the bluetooth device
3. select and connect it
then everything is ok.

I don't konw why I can't connect my bluetooth speaker wituout delete it.

zhang sheng (langyxxl) on 2016-06-25
summary: - 15:10: bluetoothd reports "Not enough handles to register service" at
- start
+ 15:10 and 16.04: bluetoothd reports "Not enough handles to register
+ service" at start

I messed around with this for ages with no luck on my Dell XPS 13 9350. It seemed to even screw up the bluetooth when I rebooted back into windows where I wasn't able to remove and re-pair my Microsoft Sculpt Comfort Mouse.

Then through freak chance I plugged in an older microsoft usb mouse (with the nano transceiver) and started using that. Not sure why but later on I retried connecting my Sculpt bluetooth mouse and boom - it worked straight away.

Was having the same trouble with bluetooth on my other laptop ASUS Zenbook 305CA but did a full reinstall (Linux Mint 18) with only the usb mouse plugged in. After install - tried to connect the bluetooth mouse and it connected first time.

I'm aware that the usb mouse thing could be a total red herring but for me it is the only thing I can think of out of everything I was trying that actually made a difference - and on 2 different laptops so I'm thinking there might be something there for other people to at least try :/

Behrang (behrangsa) wrote :
Download full text (6.1 KiB)

This affects me too:

$ journalctl | grep -i bluetooth
Jul 16 16:58:40 machine kernel: Bluetooth: Core ver 2.21
Jul 16 16:58:40 machine kernel: Bluetooth: HCI device and connection manager initialized
Jul 16 16:58:40 machine kernel: Bluetooth: HCI socket layer initialized
Jul 16 16:58:40 machine kernel: Bluetooth: L2CAP socket layer initialized
Jul 16 16:58:40 machine kernel: Bluetooth: SCO socket layer initialized
Jul 16 16:58:40 machine kernel: Bluetooth: HCI UART driver ver 2.3
Jul 16 16:58:40 machine kernel: Bluetooth: HCI UART protocol H4 registered
Jul 16 16:58:40 machine kernel: Bluetooth: HCI UART protocol BCSP registered
Jul 16 16:58:40 machine kernel: Bluetooth: HCI UART protocol LL registered
Jul 16 16:58:40 machine kernel: Bluetooth: HCI UART protocol ATH3K registered
Jul 16 16:58:40 machine kernel: Bluetooth: HCI UART protocol Three-wire (H5) registered
Jul 16 16:58:40 machine kernel: Bluetooth: HCI UART protocol Intel registered
Jul 16 16:58:40 machine kernel: Bluetooth: HCI UART protocol BCM registered
Jul 16 16:58:40 machine kernel: Bluetooth: HCI UART protocol QCA registered
Jul 16 16:58:41 machine kernel: Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014
Jul 16 16:58:41 machine kernel: Bluetooth: hci0: Device revision is 5
Jul 16 16:58:41 machine kernel: Bluetooth: hci0: Secure boot is enabled
Jul 16 16:58:41 machine kernel: Bluetooth: hci0: OTP lock is enabled
Jul 16 16:58:41 machine kernel: Bluetooth: hci0: API lock is enabled
Jul 16 16:58:41 machine kernel: Bluetooth: hci0: Debug lock is disabled
Jul 16 16:58:41 machine kernel: Bluetooth: hci0: Minimum firmware build 1 week 10 2014
Jul 16 16:58:41 machine kernel: Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi
Jul 16 16:58:41 machine NetworkManager[898]: <info> [1468652321.0800] Loaded device plugin: NMBluezManager (/usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-bluetooth.so)
Jul 16 16:58:41 machine kernel: Bluetooth: hci0: Failed to send firmware data (-38)
Jul 16 16:58:43 machine kernel: Bluetooth: hci0 command 0xfc05 tx timeout
Jul 16 16:58:47 machine kernel: Bluetooth: hci0: Reading Intel version information failed (-19)
Jul 16 16:58:48 machine systemd[1]: Starting Bluetooth service...
Jul 16 16:58:48 machine bluetoothd[1482]: Bluetooth daemon 5.37
Jul 16 16:58:48 machine bluetoothd[1482]: Starting SDP server
Jul 16 16:58:48 machine systemd[1]: Started Bluetooth service.
Jul 16 16:58:48 machine systemd[1]: Reached target Bluetooth.
Jul 16 16:58:48 machine systemd[1]: bluetooth.target: Unit not needed anymore. Stopping.
Jul 16 16:58:48 machine systemd[1]: Stopped target Bluetooth.
Jul 16 16:58:48 machine kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Jul 16 16:58:48 machine kernel: Bluetooth: BNEP filters: protocol multicast
Jul 16 16:58:48 machine kernel: Bluetooth: BNEP socket layer initialized
Jul 16 16:58:48 machine bluetoothd[1482]: Bluetooth management interface 1.10 initialized
Jul 16 16:58:48 machine kernel: Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014
Jul 16 16:58:48 machine kernel: Bluetooth: hci0: Device revision is 5
Jul 16 16:58:48 machine kernel: Bluetooth: hci0: Secure boot is enabled
Jul 16 1...

Read more...

Related bugs: https://goo.gl/jh8wuP

I got this after accidentally starting the bluetooth service while playing audio via a2dp.
The hackaround from #4 worked for me.

Gennadii Kurabko (geku) wrote :

I've enabled extended and debug logging (-E -d) in file: /lib/systemd/system/bluetooth.service

was: ExecStart=/usr/lib/bluetooth/bluetoothd
now: ExecStart=/usr/lib/bluetooth/bluetoothd -E -d

Please find logs below, in attachments. Hope it will help to pin down the problem.

$ uname -a
Linux xxx 4.4.0-45-generic #66-Ubuntu SMP Wed Oct 19 14:12:05 UTC 2016 i686 i686 i686 GNU/Linux

BlueZ version 5.37

$ journalctl --unit=bluetooth

welch (quietplease) wrote :

Also experiencing this problem, on a pristine install of ubuntu 16.04.1 LTS
(4.4.0-45-generic #66-Ubuntu SMP, BlueZ version 5.37) onto a NUC6i5SYH.

I am doing nothing on the box, just setting it up.
The only packages I've installed are for sshd and bluez.

First run of the bluetooth service worked (well, discovery
worked, though I was unable to successfully connect to
the discovered lenovo edge keyboard).

After reboot, bluetooth service is failing same as others report:

----------------------------------------------------------
```
Oct 27 09:07:15 jukebox bluetoothd[1695]: Bluetooth daemon 5.37
Oct 27 09:07:15 jukebox bluetoothd[1695]: Starting SDP server
Oct 27 09:07:15 jukebox systemd[1]: Started Bluetooth service.
Oct 27 09:07:15 jukebox bluetoothd[1695]: Bluetooth management interface 1.10 initialized
Oct 27 09:07:15 jukebox bluetoothd[1695]: Failed to obtain handles for "Service Changed" characteristic
Oct 27 09:07:15 jukebox bluetoothd[1695]: Not enough free handles to register service
Oct 27 09:07:15 jukebox bluetoothd[1695]: Error adding Link Loss service
Oct 27 09:07:15 jukebox bluetoothd[1695]: Not enough free handles to register service
Oct 27 09:07:15 jukebox bluetoothd[1695]: Not enough free handles to register service
Oct 27 09:07:15 jukebox bluetoothd[1695]: Not enough free handles to register service
Oct 27 09:07:15 jukebox bluetoothd[1695]: Current Time Service could not be registered
Oct 27 09:07:15 jukebox bluetoothd[1695]: gatt-time-server: Input/output error (5)
Oct 27 09:07:15 jukebox bluetoothd[1695]: Not enough free handles to register service
Oct 27 09:07:15 jukebox bluetoothd[1695]: Not enough free handles to register service
Oct 27 09:07:15 jukebox bluetoothd[1695]: Sap driver initialization failed.
Oct 27 09:07:15 jukebox bluetoothd[1695]: sap-server: Operation not permitted (1)
```

冯宇 (abcfy2) wrote :
Download full text (6.6 KiB)

Same issue here, bluetooth mouse often hans.

journalctl --unit=bluetooth
-- Logs begin at 日 2016-12-11 10:01:22 CST, end at 日 2016-12-11 11:32:43 CST. --
12月 11 10:01:25 fengyu-laptop bluetoothd[2142]: Bluetooth daemon 5.37
12月 11 10:01:25 fengyu-laptop bluetoothd[2142]: Starting SDP server
12月 11 10:01:25 fengyu-laptop systemd[1]: Starting Bluetooth service...
12月 11 10:01:25 fengyu-laptop bluetoothd[2142]: Bluetooth management interface 1.10 initialized
12月 11 10:01:25 fengyu-laptop bluetoothd[2142]: Failed to obtain handles for "Service Changed" characteristic
12月 11 10:01:25 fengyu-laptop bluetoothd[2142]: Not enough free handles to register service
12月 11 10:01:25 fengyu-laptop bluetoothd[2142]: Error adding Link Loss service
12月 11 10:01:25 fengyu-laptop bluetoothd[2142]: Not enough free handles to register service
12月 11 10:01:25 fengyu-laptop bluetoothd[2142]: Not enough free handles to register service
12月 11 10:01:25 fengyu-laptop bluetoothd[2142]: Not enough free handles to register service
12月 11 10:01:25 fengyu-laptop bluetoothd[2142]: Current Time Service could not be registered
12月 11 10:01:25 fengyu-laptop bluetoothd[2142]: gatt-time-server: Input/output error (5)
12月 11 10:01:25 fengyu-laptop bluetoothd[2142]: Not enough free handles to register service
12月 11 10:01:25 fengyu-laptop bluetoothd[2142]: Not enough free handles to register service
12月 11 10:01:25 fengyu-laptop bluetoothd[2142]: Sap driver initialization failed.
12月 11 10:01:25 fengyu-laptop bluetoothd[2142]: sap-server: Operation not permitted (1)
12月 11 10:01:25 fengyu-laptop systemd[1]: Started Bluetooth service.
12月 11 10:01:27 fengyu-laptop bluetoothd[2142]: Endpoint registered: sender=:1.29 path=/MediaEndpoint/A2DPSource
12月 11 10:01:27 fengyu-laptop bluetoothd[2142]: Endpoint registered: sender=:1.29 path=/MediaEndpoint/A2DPSink
12月 11 10:07:31 fengyu-laptop bluetoothd[2142]: Unable to register GATT service with handle 0x000c for device C5:5B:CD:DB:C5:D1
12月 11 10:07:31 fengyu-laptop bluetoothd[2142]: Unable to register GATT service with handle 0x0017 for device C5:5B:CD:DB:C5:D1
12月 11 10:07:31 fengyu-laptop bluetoothd[2142]: Unable to register GATT service with handle 0x001b for device C5:5B:CD:DB:C5:D1
12月 11 11:16:20 fengyu-laptop bluetoothd[2142]: Unable to register GATT service with handle 0x000c for device C5:5B:CD:DB:C5:D1
12月 11 11:16:20 fengyu-laptop bluetoothd[2142]: Unable to register GATT service with handle 0x0017 for device C5:5B:CD:DB:C5:D1
12月 11 11:16:20 fengyu-laptop bluetoothd[2142]: Unable to register GATT service with handle 0x001b for device C5:5B:CD:DB:C5:D1
12月 11 11:18:09 fengyu-laptop bluetoothd[2142]: Unable to register GATT service with handle 0x000c for device C5:5B:CD:DB:C5:D1
12月 11 11:18:09 fengyu-laptop bluetoothd[2142]: Unable to register GATT service with handle 0x0017 for device C5:5B:CD:DB:C5:D1
12月 11 11:18:09 fengyu-laptop bluetoothd[2142]: Unable to register GATT service with handle 0x001b for device C5:5B:CD:DB:C5:D1
12月 11 11:26:21 fengyu-laptop bluetoothd[2142]: Unable to register GATT service with handle 0x000c for device C5:5B:CD:DB:C5:D1
12月 11 11:26:21 fengyu-laptop bluetoothd[2142]: Unable to register GATT s...

Read more...

Ubfan (ubfan1) wrote :

On Lenovo w520, Ubuntu 16.04, kernel 4.4.0-57-generic, bluez 5.37-0ubuntu5, unity desktop.
Same error messages relating to "Not enough free handles to register service".
Resuming from suspend results in bluetooth icon in title bar grayed out, bluetooth switch is OFF, and bt mouse non-functional. Invoking the bluetooth settings from the icon shows bt switch ON. From the settings, turn bluetooth OFF, then ON again, then in the title bar icon, turn bluetooth ON also, then the mouse will connect. Happens 10-20% of the time resuming from suspend, greatly improved from kernel 4.4.0-32.

Willem Hobers (whobers) wrote :

See question https://answers.launchpad.net/ubuntu-gnome/+question/424983 also.

I also see the message "Not enough free handles to register service".

Lenovo Ideapad 110.
Linux LPTP001 4.4.0-57-generic #78-Ubuntu SMP Fri Dec 9 23:50:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Dec 31 16:02:49 LPTP001 bluetoothd[1075]: Bluetooth daemon 5.37
Dec 31 16:02:49 LPTP001 bluetoothd[1075]: Unknown key AutoEnable in main.conf
Dec 31 16:02:49 LPTP001 bluetoothd[1075]: Starting SDP server
Dec 31 16:02:49 LPTP001 bluetoothd[1075]: Bluetooth management interface 1.10 initialized
Dec 31 16:02:49 LPTP001 bluetoothd[1075]: Failed to obtain handles for "Service Changed" characteristic
Dec 31 16:02:49 LPTP001 bluetoothd[1075]: Not enough free handles to register service
Dec 31 16:02:49 LPTP001 bluetoothd[1075]: Error adding Link Loss service
Dec 31 16:02:49 LPTP001 bluetoothd[1075]: Not enough free handles to register service
Dec 31 16:02:49 LPTP001 bluetoothd[1075]: message repeated 2 times: [ Not enough free handles to register service]
Dec 31 16:02:49 LPTP001 bluetoothd[1075]: Current Time Service could not be registered
Dec 31 16:02:49 LPTP001 bluetoothd[1075]: gatt-time-server: Input/output error (5)
Dec 31 16:02:49 LPTP001 bluetoothd[1075]: Not enough free handles to register service
Dec 31 16:02:49 LPTP001 bluetoothd[1075]: Not enough free handles to register service
Dec 31 16:02:49 LPTP001 bluetoothd[1075]: Sap driver initialization failed.
Dec 31 16:02:49 LPTP001 bluetoothd[1075]: sap-server: Operation not permitted (1)
Dec 31 16:02:49 LPTP001 NetworkManager[868]: <info> [1483196569.9018] bluez: use BlueZ version 5
Dec 31 16:03:00 LPTP001 bluetoothd[1075]: Endpoint registered: sender=:1.40 path=/MediaEndpoint/A2DPSource
Dec 31 16:03:00 LPTP001 bluetoothd[1075]: Endpoint registered: sender=:1.40 path=/MediaEndpoint/A2DPSink
Dec 31 16:03:08 LPTP001 bluetoothd[1075]: Endpoint registered: sender=:1.64 path=/MediaEndpoint/A2DPSource
Dec 31 16:03:08 LPTP001 bluetoothd[1075]: Endpoint registered: sender=:1.64 path=/MediaEndpoint/A2DPSink
Dec 31 16:03:08 LPTP001 bluetoothd[1075]: RFCOMM server failed for Headset Voice gateway: rfcomm_bind: Address already in use (98)
Dec 31 16:03:35 LPTP001 gnome-bluetooth-panel.desktop[2274]: ** (gnome-control-center:2274): WARNING **: Ignoring launcher gufw (missing desktop file)
Dec 31 16:03:35 LPTP001 gnome-bluetooth-panel.desktop[2274]: ** (gnome-control-center:2274): WARNING **: Ignoring launcher landscape-client-settings (missing desktop file)
Dec 31 16:03:35 LPTP001 gnome-bluetooth-panel.desktop[2274]: ** (gnome-control-center:2274): WARNING **: Ignoring launcher language-selector (missing desktop file)
Dec 31 16:03:35 LPTP001 gnome-bluetooth-panel.desktop[2274]: ** (gnome-control-center:2274): WARNING **: Ignoring launcher ubuntuone-installer (missing desktop file)
Dec 31 16:03:35 LPTP001 /usr/lib/gdm3/gdm-x-session[1652]: Activating service name='org.bluez.obex'
Dec 31 16:03:35 LPTP001 /usr/lib/gdm3/gdm-x-session[1652]: Successfully activated service 'org.bluez.obex'
Dec 31 16:04:45 LPTP001 bluetoothd[1075]: connect error: Connection refused (111)

aromo (aromo) wrote :

Hi all,

This bug affects me: Can't connect to my UE BOOM bluetooth speakers, when I mess around with configuration and make it connect, the speaker doesn't show up on the list of available speakers (Settings > Sound), therefore, can't make them work.

16.04.1 LTS, kernel 4.4.0-59-generic.
#4 and #26 didn't make any change. Net thing to try is downgrade to 4.3.6 if that's possible.
logs:
Jan 22 13:48:07 Laptop5 systemd[1]: Starting Bluetooth service...
Jan 22 13:48:08 Laptop5 bluetoothd[919]: Bluetooth daemon 5.37
Jan 22 13:48:10 Laptop5 systemd[1]: Started Bluetooth service.
Jan 22 13:48:14 Laptop5 bluetoothd[919]: Starting SDP server
Jan 22 13:48:16 Laptop5 bluetoothd[919]: Bluetooth management interface 1.10 initialized
Jan 22 13:48:16 Laptop5 bluetoothd[919]: Failed to obtain handles for "Service Changed" characteristic
Jan 22 13:48:16 Laptop5 bluetoothd[919]: Not enough free handles to register service
Jan 22 13:48:16 Laptop5 bluetoothd[919]: Error adding Link Loss service
Jan 22 13:48:16 Laptop5 bluetoothd[919]: Not enough free handles to register service
Jan 22 13:48:16 Laptop5 bluetoothd[919]: Not enough free handles to register service
Jan 22 13:48:16 Laptop5 bluetoothd[919]: Not enough free handles to register service
Jan 22 13:48:16 Laptop5 bluetoothd[919]: Current Time Service could not be registered
Jan 22 13:48:16 Laptop5 bluetoothd[919]: gatt-time-server: Input/output error (5)
Jan 22 13:48:16 Laptop5 bluetoothd[919]: Not enough free handles to register service
Jan 22 13:48:16 Laptop5 bluetoothd[919]: Not enough free handles to register service
Jan 22 13:48:16 Laptop5 bluetoothd[919]: Sap driver initialization failed.
Jan 22 13:48:16 Laptop5 bluetoothd[919]: sap-server: Operation not permitted (1)
Jan 22 13:48:24 Laptop5 bluetoothd[919]: Endpoint registered: sender=:1.35 path=/MediaEndpoint/A2DPSource
Jan 22 13:48:24 Laptop5 bluetoothd[919]: Endpoint registered: sender=:1.35 path=/MediaEndpoint/A2DPSink
Jan 22 09:48:17 Laptop5 bluetoothd[919]: Endpoint registered: sender=:1.64 path=/MediaEndpoint/A2DPSource
Jan 22 09:48:17 Laptop5 bluetoothd[919]: Endpoint registered: sender=:1.64 path=/MediaEndpoint/A2DPSink
Jan 22 09:48:17 Laptop5 bluetoothd[919]: RFCOMM server failed for Headset Voice gateway: rfcomm_bind: Address already in use (98)
Jan 22 09:59:10 Laptop5 bluetoothd[919]: Device is already marked as connected
Jan 22 09:59:10 Laptop5 bluetoothd[919]: Unable to register GATT service with handle 0x0001 for device 88:C6:26:1E:4B:63
Jan 22 09:59:41 Laptop5 bluetoothd[919]: Unable to register GATT service with handle 0x0001 for device 88:C6:26:1E:4B:63
Jan 22 10:00:12 Laptop5 bluetoothd[919]: Unable to register GATT service with handle 0x0001 for device 88:C6:26:1E:4B:63 <== keeps repeating forever

Any permanent solution to this bug on sight? Thank you.

Charlie Knight (cyano) wrote :

@aromo Similar issue, couldn't connect UE Boom speaker was just getting 'Unable to register GATT service with handle 0x0001'. Found it strange that even when the speaker was powered down bluetoothd kept trying to connect (and disconnect seconds later)

What I found was, UE Boom speakers can be powered on remotely using the mobile application - which is done through Bluetooth LE. This is why the speaker was connected even when powered-down because of it was connected via LE. I could be wrong but I believe the GATT service manages the messages from LE devices - So I tried disabling Bluetooth Low Energy on the laptop bluetooth adaptor through this command:

sudo btmgmt le off

Unpaired the speaker, restarted the laptop and afterwards I had no more "Unable to Register GATT" or "Device is already marked connected messages" and I was able to connect the speaker through Audio Sink. Haven't had any issues with it since (except for having to run a2dp.py - but that is a separate issue)

Perhaps you could try disabling le and see if it works for you too?

Willem Hobers (whobers) wrote :

Thanks for your suggestion; happy to try any solution suggestions.

When entering the command I get:

Set Low Energy for hci0 failed with status 0x0a (Busy)

Tried finding more information about this message but couldn't find anything which seemed relevant.
Any suggestions?

(BTW: just to be clear: still no working connection with the bluetooth device.)

Willem Hobers (whobers) wrote :

Just to -perhaps- add to any confusion: when I submit the command "sudo btmgmt le off" in terminal, I expected the command to simply do its thing (switch off le) and then return cli to the "waiting for input" status. Well, it doesn't: when I submit the command and enter my password and press <enter> nothing happens. To get back to "input mode" in terminal I have to press CTRL-C.
(I hope this description makes any sense.)

Is this normal behaviour?

Charlie Knight (cyano) wrote :

I just tried running the command to turn off le when connected to a device and I got the same message 'status 0x0a (Busy)' so perhaps you are already connected to something.

My suggestion is to unpair all devices (if you have any paired) and running the command:
rfkill block bluetooth

That command soft blocks the bluetooth adapter - so it won't be able to attempt any connections. After is it blocked try running the le commannd again (sudo btmgmt le off)

Then unblock the bluetooth adapter by: rfkill unblock bluetooth.

Jack Martin (trancelover) wrote :

I was receiving many of the same errors in my logs, and after about 15+ fixes I tried, this was what ended up working. My main issue wasn't really connecting the headset, it was keeping it connected for more than a couple seconds and being able to play a2dp. Hopefully this works for some of you.

Go into bluetoothctl and set your device to trust

# bluetoothctl
# devices
    Device XX:XX:XX:XX:XX:XX
# trust XX:XX:XX:XX:XX:XX

Nick T (n1ck) wrote :

Just to note that I had similar problems that were solved by cyano's suggestion in #32
(Using Ubuntu 16.04 LTS with a cheap CSR8510 chip USB bluetooth dongle and Clarity bluetooth speaker.)

sudo btmgmt le off

Then using the standard Bluetooth Settings app deleted the current connection from the list of devices and remade the connection. This resolved the problem.

However, in order to get the speaker to appear in the list of output devices in Sound Settings I find I always have to switch the bluetooth connection to the Clarity speaker on, then off, then on again at the start of a session (using the Bluetooth notification area drop-down). After that, it's fine for the remainder of the session.

On Ubuntu 16.10 with this bluez package:

Package: bluez
Version: 5.41-0ubuntu3with

I no longer see the "Not enough handles to register service" messages.

tags: added: xenial
Changed in bluez (Ubuntu):
importance: Undecided → High
umoser (ulrich-moser) wrote :

In Ubuntu 16.04 LTS the error still persists. Should be fixed asap since it affects any notebook I am running on 16.04 LTS.

summary: - 15:10 and 16.04: bluetoothd reports "Not enough handles to register
+ 15:10 and 16.04: bluetoothd reports "Not enough free handles to register
service" at start

Encountered today on Ubuntu 16.04 quite surprisingly, as bluetooth is usually problematic (with https://bugs.launchpad.net/bugs/1577197 ), but not broken.

Disabling LE did not resolve issue. I'm expecting (hoping) rebooting will, since it worked before.

Same experience as #40 after installing updates on 16.04 today.
I already have the workaround from #4 applied.
The workaround from #35 appears to still work, thankfully.

Arun VC (arunvc) wrote :

I deleted ~/.config/pulse

and it solved this issue

as discussed in https://bbs.archlinux.org/viewtopic.php?id=195886&p=2

Daniel van Vugt (vanvugt) wrote :

That sounds like an excellent workaround. It's probably not a fix though. A fix would involve finding out why the config has confused bluez.

Actually this sounds like an "old" bug that was fixed after 16.04 since newer releases aren't being reported. If we could figure out what fixed it then we could backport that fix to 16.04. You can search the code here:
   https://git.kernel.org/pub/scm/bluetooth/bluez.git

Daniel van Vugt (vanvugt) wrote :
Changed in bluez (Ubuntu):
assignee: nobody → Daniel van Vugt (vanvugt)
Ahmed Sabry (abou7mied) wrote :

Same error on Ubuntu 16.04 LTS
I tried all the workaround mentioned here and still same error
Is there any updates for this bug?

Daniel van Vugt (vanvugt) wrote :

I am aiming to investigate comment #44 a bit more this week. If it solves the problem then I would aim to release that fix to 16.04...

Daniel van Vugt (vanvugt) wrote :

Well that didn't work. I backported f558fca8d64e3795b0654a90d343af1dd1d8b33c to xenial and found it only fixed "Failed to obtain handles for "Service Changed" characteristic" but not the errors immediately after it: "Not enough free handles to register service".

Sounds like that commit is not related to this bug. Also that commit didn't get released till Bluez 5.44 so it was solving a problem that existed in all Ubuntu releases (till artful got 5.45 last week).

If this bug however was fixed in 16.10 or 17.04 then the fix must have been something different.

description: updated
summary: - 15:10 and 16.04: bluetoothd reports "Not enough free handles to register
- service" at start
+ 15:10 and 16.04: bluetoothd "Failed to start discovery:
+ org.bluez.Error.NotReady" after bluetoothd restarted
description: updated
Daniel van Vugt (vanvugt) wrote :

Sorry for the confusion (which actually seems to have started in comment #1 :).

This bug is not about "Not enough free handles to register service".

This bug (as first reported by TJ) is about "Failed to start discovery: org.bluez.Error.NotReady" which happens after restarting the daemon. And actually, it seems that's not a bug. "scan on" fails because the controller (your bluetooth hardware) is turned off by default. All you need to do is type "power on" before "scan on".

If anyone would like to log a separate bug for "Not enough free handles to register service" then please feel free :)

Changed in bluez (Ubuntu):
status: Confirmed → Invalid
assignee: Daniel van Vugt (vanvugt) → nobody
abhijit (abhijitw143) on 2017-07-22
Changed in bluez (Ubuntu):
status: Invalid → Confirmed
Changed in bluez (Ubuntu):
status: Confirmed → Invalid
doru001 (headset001) wrote :

https://stackoverflow.com/questions/29891254/bluez-5-30-not-enough-free-handles-to-register-service-error-in-starting-blue
Apr 27 '15
"I dived into the code for debugging the issue a little bit. The attrib_db_find_avail(adapter, svc_uuid, size)[in function: gatt_service_add()] always return 0. the root cause is the servers glist parameter is always NULL, which is in g_slist_find_custom(servers, adapter, adapter_cmp)[called from find_uuid16_avail()/find_uuid128_avail()].
I noticed there is the call: **btd_adapter_gatt_server_start**(struct btd_adapter *adapter)to be used to add a server into the servers glist. But the weird thing is no where it gets called through the whole bluez source code tree.

So shall I call btd_adapter_gatt_server_start() somewhere in my code? or any other steps I should do to resolve the issue?
thanks!"

doru001 (headset001) wrote :

I succeeded to connect only from GUI, Ubuntu 16.04, xfce4, from applet, probably using blueman-manager and associated GUI only commands.

Daniel van Vugt (vanvugt) wrote :

That appears to be a different bug. Also, this bug is closed.

If you have any issues at all in future then please open a new bug.

Rajesh (theperfe) wrote :

This may not be a bug. Even I faced this error which seems to be related to another error, blueman.bluez.errors.DBusFailedError for which I found the solution here: https://askubuntu.com/questions/801404/bluetooth-connection-failed-blueman-bluez-errors-dbusfailederror-protocol-no.

Hope this may help someone.

gcchen (gcchen-org) wrote :

My laptop runs ubuntu 16.04. Linux: 4.4.0-93-generic
I tried to debug this issue by compiling bluetoothd from source code.
Surprisingly, this issue is fixed after executing newly compiled bluetoothd instead of /usr/lib/bluetooth/bluetoothd.
Steps to build and run newly compiled bluetoothd is listed below.

sudo systemctl disable bluetooth.service
sudo systemctl stop bluetooth.service
* make sure bluetoothd started by systemd is stopped.
sudo systemctl status bluetooth.service

* build bluetoothd
mkdir test
cd test/
apt-get source bluez
cd bluez-5.37/
sudo apt-get install libglib2.0-dev
sudo apt-get install libdbus-1-dev
sudo apt-get install libudev-dev
sudo apt-get install libical-dev
sudo apt-get install lib64readline-dev
sudo apt-get install libreadline-dev
./configure
make
cd src/
ls
sudo ./bluetoothd -n
bluetooth may work now.

The drawback is that you have to start bluetoothd manually after reboot.
Good luck.

Daniel van Vugt (vanvugt) wrote :

Everyone please open new bugs instead of commenting here.

This bug is closed per comment #48.

JeWu (eve-on) wrote :

Same issue here with Mint 18.2 Cinnamon and HID Logitech Mouse M535.
No matter which Kernel i used (from 4.8-x to 4.13.0-17) the same issue occured again.

I finally got it working again by issuing the command

sudo bluetoothctl
>power off
>power on
>quit

After that, wWhile running bluewho besides blueman, I finally managed to pair the frickin thing again.

Hope it lasts.

WinEunuchs2Unix (ricklee518) wrote :

This bug effects 128 people and closing it because you don't like the title feels wrong. Two Ask Ubuntu questions point to this Lanuchpad bug report in the hopes it will be solved:

https://askubuntu.com/questions/757396/bluetooth-how-to-solve-not-enough-free-handles-to-register-service-error

and

https://askubuntu.com/questions/773629/16-04-bluetooth-error-not-enough-free-handles-to-register-service

A Debian bug report suggests a solution by using -E (experimental) parameter on the systemd service exec doesn't work for Ubuntu 16.04, Kernel 4.14.4: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813949

When a hundred reported people are effected by "Not enough free handles to register service" and you don't want to look at it because the bug title isn't right, why not simply change the title?

Something else to consider are the thousands of people effected by bluetooth connection problems, re-pairing, etc. What if the root of their problems was this bug that you don't want to look at?

WinEunuchs2Unix (ricklee518) wrote :

Complement to #56, Ubuntu 16.04.3, Kernel 4.14.4, journalctl -b:

Dec 13 20:44:33 alien bluetoothd[928]: Failed to obtain handles for "Service Changed" characteristic
Dec 13 20:44:33 alien bluetoothd[928]: Not enough free handles to register service
Dec 13 20:44:33 alien bluetoothd[928]: Error adding Link Loss service
Dec 13 20:44:33 alien bluetoothd[928]: Not enough free handles to register service
Dec 13 20:44:33 alien bluetoothd[928]: Not enough free handles to register service
Dec 13 20:44:33 alien bluetoothd[928]: Not enough free handles to register service
Dec 13 20:44:33 alien bluetoothd[928]: Current Time Service could not be registered
Dec 13 20:44:33 alien bluetoothd[928]: gatt-time-server: Input/output error (5)
Dec 13 20:44:33 alien bluetoothd[928]: Not enough free handles to register service
Dec 13 20:44:33 alien bluetoothd[928]: Not enough free handles to register service

Daniel van Vugt (vanvugt) wrote :

Yes I understand you and most people are asking for a resolution to "Not enough free handles to register service". However it is better for a bug's resolution if we focus on the problem that the original reporter was trying to describe. And that's a very different, unrelated problem.

We certainly could rename this bug and commandeer it to be about "Not enough free handles to register service". But there's probably no need for that.

If anyone would like a resolution to "Not enough free handles to register service" then please start by opening a bug for it here: https://bugs.launchpad.net/ubuntu/+source/bluez/+filebug

Very simple and very clean.

Jason Owen (jason-a-owen) wrote :

The original bug title was '15:10: bluetoothd reports "Not enough handles to register service" at start', and the original bug description described both the "Not enough free handles to register service" problem and the "Failed to start discovery" problem[1]. Between #47 and #48, the title and description were changed to focus on the "Failed to start discovery" problem.

It seems to me that most of the people in the thread are focused on the "Not enough free handles to register service", and aside from the close message in #48, the only mention of the "Failed to start discovery" problem was in the original description. Perhaps it would be useful to split the "Failed to start discovery" problem off into its own bug and keep this bug focused on "Not enough free handles to register service"? That way the history and relevant log files are all kept in one place, subscribers won't have to subscribe to another bug, and links pointing to this bug for the "Not enough free handles to register service" problem won't need to be updated.

[1] https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1490349/comments/0

Daniel van Vugt (vanvugt) wrote :

Yes the bug title changed but the problem the original reporter was describing in the bug description did not. The original description and the current description both say:

  "On 15:10 after the bluetooth service has been stopped and restarted it is not possible to scan or connect to devices:"

Thus the original bug title was just a mistake, which has been corrected.

It is inappropriate to commandeer and change the direction of a bug from the intent of the original reporter because at any stage they do have the right to change it back, or to proclaim that some eventual fix does or does not resolve the original problem.

There are only 28 people, not 128, really subscribed to this bug. I'm sure one of you could just follow this link and open a new bug: https://bugs.launchpad.net/ubuntu/+source/bluez/+filebug

It is actually pretty common for people to say "hey that bug you closed doesn't fix the problem for me". However the bug should still remain closed unless those people happen to be the original reporter. So in that case, yes, if TJ was willing to change the description of this bug to be about the problem you describe rather than the original problem s/he reported then that's possibly OK.

ken (no-name1) wrote :

first thing first: bluetooth device can be paired with command line.

I have the same error on my eOS/ubuntu 16.04, "bluetoothd[17440]: Not enough free handles to register service", and have tried many many options, have desprated for a year.

and today I've success connected my bluetooth headset via command line. following struction provided by "jeremy31" here at #4 : https://ubuntuforums.org/showthread.php?t=2338474

ps. at first the sound was config to use hsf/hfp be default, which will gave you horrible sound, change to A2DP Slink in pulseAudio will get much better sound.

ps 2. after pair device via command line, the headset is show in system setting/bluetooth list. but new device can only be added via command line.

hope this can help someone.

Daniel van Vugt (vanvugt) wrote :

This bug is closed. If you have any issues at all, please log a new bug by running this command:

  ubuntu-bug bluez

Jeremy Walker (machineghost) wrote :

Look, obviously you can't solve all bugs in a single ticket, or you'd never get anything done.

However, if you've got more than a hundred people who will still have a problem after a bug is closed, that means there needs to be a new bug created for it, *by the maintainers*! Otherwise you're doing the digital equivalent of sweeping the problem under the rug.

This is how it works on every other ticket system. No one else closes a bug and says "hey 100+ users whose problem is not actually fixed ... your problem is fixed! And as a result no other fixes ... like the kind that might actually fix your problem ... will be coming."

You can't just screw over 100+ *reporters* (and who knows how many other affected people) by guaranteeing they'll never get a fix, or at best by delaying their fix while you wait for someone to file a new ticket, all so that you can get one more "fixed bug" on your belt notch.

You clearly understand the issue, you know the technical details, and you can create a new ticket in all of two minutes. Doing so would get the ball rolling on an actual fix for those 100+ users, instead of throwing them under the bus.

Daniel van Vugt (vanvugt) wrote :

The 100+ just means a lot of people made the same mistake, which is understandable. See comment #48.

I asked over a year ago for someone to open a new bug if they want to discuss "Not enough free handles to register service". If it was important to anyone then I'm sure someone would have done it by now.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.