Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: bluetoothctl hangs when there are no bluetooth devices. The user must terminate the command with ctrl-C. Version-Release number of selected component (if applicable): bluez-5.50-3.fc29.x86_64 kernel-4.19.12-301.fc29.x86_64 Testing was done in a VM (virt-manager/qemu) on an F28 host. How reproducible: Always. Steps to Reproduce: 1. Configure a system with no bluetooth devices. (In a VM, for example.) 2. $ bluetoothctl Actual results: bluetoothctl hangs until it is terminated with ctrl-C. Expected results: bluetoothctl exits with a message saying that there are no bluetooth devices. Additional info: Reported in: Bug 1662304 - Ralink RT3290 Is Not in Kernel (Bug 1662304, Comment 7)
$ man bluetoothctl No manual entry for bluetoothctl
The bluetooth.service doesn't start, as expected, but it doesn't log any messages: $ systemctl start bluetooth.service $ systemctl status bluetooth.service ● bluetooth.service - Bluetooth service Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:bluetoothd(8) $ journalctl -b -g 'bluetoothd' -- Logs begin at Mon 2018-10-29 19:56:54 GMT, end at Sat 2018-12-29 15:16:48 GMT. -- -- No entries -- $ cat /usr/lib/systemd/system/bluetooth.service | grep ExecStart ExecStart=/usr/libexec/bluetooth/bluetoothd
(In reply to Steve from comment #2) > ... but it doesn't log any messages: ... > $ journalctl -b -g 'bluetoothd' ... That doesn't do what I expected. This is a better test: $ journalctl -b -u bluetooth.service
This bug has a long history: bluetoothctl systematically hangs when there is no bluetooth hardware Bug #1565940 reported by Etienne URBAH on 2016-04-04 https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1565940 Also reported here: Bug_199127 - bluetoothctl systematically hangs when there is no bluetooth hardware Reported: 2018-03-15 21:28 UTC by Etienne URBAH https://bugzilla.kernel.org/show_bug.cgi?id=199127
Created attachment 1517678 [details] strace -o bluetoothctl-strace-1.txt -f -y -s 1024 bluetoothctl The problem is that bluetoothctl is connecting to dbus-daemon, but it is ignoring the reply: ... 2368 connect(4<socket:[37279]>, {sa_family=AF_UNIX, sun_path="/run/dbus/system_bus_socket"}, 29) = 0 ... 2368 recvmsg(4<socket:[37279]>, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\3\1\1:\0\0\0\4\0\0\0u\0\0\0\6\1s\0\6\0\0\0:1.346\0\0\4\1s\0) \0\0\0 org.freedesktop.DBus.Error.NameHasNoOwner \0\0\0\0\0\0\0\5\1u\0\3\0\0\0\10\1g\0\1s\0\0\7\1s\0\24\0\0\0org.freedesktop.DBus\0\0\0\0005\0\0\0 Could not get owner of name 'org.bluez': no such name \0l\2\1\1\0\0\0\0\5\0\0\0005\0\0\0\6\1s\0\6\0\0\0:1.346\0\0\5\1u\0\4\0\0\0\7\1s\0\24\0\0\0org.f reedesktop.DBus\0\0\0\0", iov_len=2048}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 266 ...
I'm afraid this isn't a bug, it's what bluetoothctl does when waiting for bluetoothd to get started, which it automatically would if there was a detected Bluetooth adapter. If you want to test for the presence of a Bluetooth device using the command-line, you should use hciconcig instead. If you don't like the behaviour of bluetoothctl, you should contact upstream on the mailing-list: http://www.bluez.org/contact/
(In reply to Bastien Nocera from comment #6) > I'm afraid this isn't a bug, it's what bluetoothctl does when waiting for > bluetoothd to get started, which it automatically would if there was a > detected Bluetooth adapter. If you want to test for the presence of a > Bluetooth device using the command-line, you should use hciconcig instead. I expect a command to terminate with a message when it is going to be waiting forever, which is what bluetoothctl is going to do when there is no daemon. As comment 5 CLEARLY shows: org.freedesktop.DBus.Error.NameHasNoOwner And after looking at the source code, it is obvious it is merely prototype code, which shouldn't be in any Fedora release. > If you don't like the behaviour of bluetoothctl, you should contact upstream > on the mailing-list: http://www.bluez.org/contact/ No. You have at least three people "don't like the behaviour of bluetoothctl", so closing this bug is simply a snub.
Adam: What do you think about bluetoothctl hanging forever when there are no bluetooth devices?
BTW, the "-ctl" suffix is used in many other command names. Here are some examples from systemd: $ rpm -ql systemd | grep '/usr/bin/.*ctl' /usr/bin/busctl /usr/bin/coredumpctl /usr/bin/hostnamectl /usr/bin/journalctl /usr/bin/localectl /usr/bin/loginctl /usr/bin/networkctl /usr/bin/systemctl /usr/bin/timedatectl More examples can be found with: $ ls -1 /usr/*bin/*ctl
(In reply to Bastien Nocera from comment #6) > ... it's what bluetoothctl does when waiting for bluetoothd to get started, ... The bluez package needs a systemd socket unit for that to happen: $ systemctl list-unit-files bluetooth.\* UNIT FILE STATE bluetooth.service enabled bluetooth.target static 2 unit files listed. $ rpm -qf /usr/lib/systemd/system/bluetooth.service bluez-5.50-1.fc28.x86_64 Compare with cups: $ systemctl list-unit-files cups.\* UNIT FILE STATE cups.path disabled cups.service disabled cups.socket disabled 3 unit files listed. (NB: I have cups disabled, but that is beside the point.)
See: systemd.socket (5) systemd-socket-activate (1)