Ubuntu
bluez package

bluetoothctl systematically hangs when there is no bluetooth hardware

Bug #1565940 reported by Etienne URBAH
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Bluez Utilities
Unknown
Unknown
bluez (Ubuntu)
Confirmed
Low
Unassigned
Nominated for Artful by Daniel van Vugt

Bug Description

On a machine WITH bluetooth hardware, the 'bluetoothctl' command works correctly.
For example, the command 'bluetoothctl < /dev/null' terminates correctly.

On a machine WITHOUT bluetooth hardware, the 'bluetoothctl' command systematically hangs.
Even the command 'bluetoothctl < /dev/null' systematically hangs.

$ bluetoothctl &
[1] 6208

$ ps -l $!
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
0 T 1001 6208 2525 0 80 0 - 9578 signal pts/1 0:00 bluetoothctl

[1]+ Stopped bluetoothctl

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: bluez 5.35-0ubuntu2
ProcVersionSignature: Ubuntu 4.2.0-34.39-generic 4.2.8-ckt4
Uname: Linux 4.2.0-34-generic x86_64
ApportVersion: 2.19.1-0ubuntu5
Architecture: amd64
CurrentDesktop: X-Cinnamon
Date: Mon Apr 4 20:09:39 2016
InstallationDate: Installed on 2015-07-20 (259 days ago)
InstallationMedia: Ubuntu-GNOME 15.04 "Vivid Vervet" - Release amd64 (20150422)
InterestingModules: bluetooth
MachineType: To be filled by O.E.M. To be filled by O.E.M.
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-34-generic.efi.signed root=UUID=0d11df61-c758-41b1-9ec3-8310bf038b07 ro quiet splash vt.handoff=7
SourcePackage: bluez
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: Upgraded to wily on 2015-10-22 (165 days ago)
dmi.bios.date: 06/26/2015
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 2603
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: M5A97 R2.0
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2603:bd06/26/2015:svnTobefilledbyO.E.M.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnASUSTeKCOMPUTERINC.:rnM5A97R2.0:rvrRev1.xx:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To be filled by O.E.M.
dmi.product.version: To be filled by O.E.M.
dmi.sys.vendor: To be filled by O.E.M.
hciconfig:

rfkill:

syslog:
 avril 03 15:10:45 urbah-sirius systemd[1]: Starting Automatic USB/Bluetooth printer setup (-devices-pci0000:00-0000:00:12.2-usb5-5\x2d5)...
 avril 03 15:10:45 urbah-sirius NetworkManager[986]: <info> Loaded device plugin: NMBluezManager (/usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-bluetooth.so)
 avril 03 15:10:50 urbah-sirius systemd[1]: Started Automatic USB/Bluetooth printer setup (-devices-pci0000:00-0000:00:12.2-usb5-5\x2d5).

Revision history for this message
Etienne URBAH (eurbah) wrote :
Revision history for this message
Etienne URBAH (eurbah) wrote :

The problem is still the same with bluez version 5.37-0ubuntu5

Revision history for this message
Etienne URBAH (eurbah) wrote :

With bluez version 5.41-0ubuntu3 :

The command 'bluetoothctl' displays 'Waiting to connect to bluetoothd...', then hangs.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Thank you for reporting this bug to Ubuntu. Ubuntu 15.10 (wily) reached end-of-life on July 28, 2016.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

Please upgrade to the latest version and re-test.

Changed in bluez (Ubuntu):
status: New → Incomplete
Revision history for this message
Etienne URBAH (eurbah) wrote :

With bluez version 5.43-0ubuntu1 from Ubuntu 17.04 (Zesty), the issue is still there :

The command 'bluetoothctl' displays 'Waiting to connect to bluetoothd...', then hangs.

tags: added: zesty
Changed in bluez (Ubuntu):
status: Incomplete → New
Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

I'm afraid that this is how the bluetoothctl is designed. This tool is a command-line interface to the bluetoothd and requires it up and running. It will not quit however when it is not running for a situations where the daemon might come back online.

Ubuntu does not do anything special here, the bluetoothctl tool is packaged as is from the upstream.

For Ubuntu this normally should not be a problem because a user is expected to use {unity,gnome}-system-settings anyway to interact with BT subsystem. Is there a particular use-case that is failing on this behavior?

Revision history for this message
Etienne URBAH (eurbah) wrote :

My particular use case is to detect, inside a shell script, if there is any bluetooth hardware at all.

Since 'bluetoothctl' systematically hangs when there is NO bluetooth hardware, I can NOT use the 'bluetoothctl' command to achieve this use case.

But I have found a good alternate method :

if rfkill list | grep -q -i Bluetooth; then ...; fi

So, the issue is NOT blocking for me.

But I suggest that 'man bluetoothctl' should indicate that 'bluetoothctl' waits (possibly indefinitely) for answers from the 'bluetoothd' daemon, and therefore is NOT adequate for scripting.

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

Now I understand your use-case.

You probably could achieve similar with $ systemctl status bluetooth.service. Also hcitool can tell if the adapter is up and running but keep in mind that hcitool is depreciated and no longer maintained by the upstream.

As for the man entry suggestion yes that could be something to consider given that the default man page is quite vague nevertheless this, as whole bluez, comes straight from the upstream.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Thank you for reporting this bug to Ubuntu.
Ubuntu 17.04 (zesty) reached end-of-life on January 13, 2018.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test.

If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in and change the bug status to Confirmed.

Changed in bluez (Ubuntu):
status: New → Incomplete
Revision history for this message
Etienne URBAH (eurbah) wrote :

With bluez version 5.46-0ubuntu3 from Ubuntu 17.10 (Artful), the issue is still there :

The command 'bluetoothctl' systematically hangs.

tags: added: artful
Changed in bluez (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I can reproduce the bug in 16.04 but it seems to be fixed in 18.04:

$ echo '' | bluetoothctl
No agent is registered
$

$ bluetoothctl < /dev/null
[bluetooth]# quitt to bluetoothd...
No agent is registered
$

I'm going to declare this fix released and nominate 17.10 for a fix (whatever the fix would be).

Changed in bluez (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

> My particular use case is to detect, inside a shell script, if there is any bluetooth hardware at all.

I suggest a better way to detect Bluetooth hardware is to check with the kernel directly:

  if /sys/class/bluetooth/ exists and is non-empty then ...

The directory is created when the first Bluetooth controller is added to the system, and becomes empty only after the last one is removed.

Revision history for this message
Etienne URBAH (eurbah) wrote :

With bluez version 5.48-0ubuntu3 from Kubuntu 18.04 Beta1 (Bionic), the issue is still there :

The command 'bluetoothctl' displays 'Waiting to connect to bluetoothd...', then hangs.

tags: added: bionic
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

OK, I can finally reproduce the problem, but I had to manually kill my bluetoothd before I could make it fail. I guess a Kubuntu session is similar to that environment. Confirmed, but low priority.

For a better idea that avoids bluetoothctl see comment #12.

Finally, please log the bug with the upstream BlueZ developers:
https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers&component=Bluetooth

and then let us know the ID of the newly-created bug.

Changed in bluez (Ubuntu):
status: Fix Released → Confirmed
importance: Undecided → Low
status: Confirmed → Incomplete
Revision history for this message
Etienne URBAH (eurbah) wrote :

I have reported this issue at https://bugzilla.kernel.org/show_bug.cgi?id=199127

Changed in bluez (Ubuntu):
status: Incomplete → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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