How to recover from stuck Bluetooth scan ?
-
My primary reason for ditching "brand X " Bluetooth API was its lacking of resetting the discovered Bluetooth devices. I am now using "hcitool scan flush " which does reset the data and then does real scan. The "hcitool" command responds with a message "Scanning" and takes up to 30 seconds to finish. There is yet another issue here - sometime it gets stuck in "scanning" and only reasonable way to recover is to reboot the system... ( The API I am using monitors the scanning time and can be adjusted , I have not look into that , not yet. ) That is silly and unacceptable. How safe or dangerous would it be to stop and restart the Linux Bluetooth service itself ?
-
My primary reason for ditching "brand X " Bluetooth API was its lacking of resetting the discovered Bluetooth devices. I am now using "hcitool scan flush " which does reset the data and then does real scan. The "hcitool" command responds with a message "Scanning" and takes up to 30 seconds to finish. There is yet another issue here - sometime it gets stuck in "scanning" and only reasonable way to recover is to reboot the system... ( The API I am using monitors the scanning time and can be adjusted , I have not look into that , not yet. ) That is silly and unacceptable. How safe or dangerous would it be to stop and restart the Linux Bluetooth service itself ?
Why should that be dangerous? Windows updated here and there was a power failure. (Do not turn of your machine?) It just kept working.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
My primary reason for ditching "brand X " Bluetooth API was its lacking of resetting the discovered Bluetooth devices. I am now using "hcitool scan flush " which does reset the data and then does real scan. The "hcitool" command responds with a message "Scanning" and takes up to 30 seconds to finish. There is yet another issue here - sometime it gets stuck in "scanning" and only reasonable way to recover is to reboot the system... ( The API I am using monitors the scanning time and can be adjusted , I have not look into that , not yet. ) That is silly and unacceptable. How safe or dangerous would it be to stop and restart the Linux Bluetooth service itself ?
Member 14968771 wrote:
How safe or dangerous would it be to stop and restart the Linux Bluetooth service itself ?
It should not affect the running of the Linux system at all. It might leave any connected bluetooth devices "orphaned", I.E. with a connection that the kernel doesn't know about, but I really do not know. You almost certainly can't damage the linux system beyond needing a reboot to get back to where you were, so if I were you I'd try it and see what effect it has. In particular I'd look to see if currently connected devices keep working, and if the stuck process recovers quickly after the restart. I suspect that restarting the service won't affect the stuck hcitool process. It probably has all it needs to do its work, so restarting the bluetooth service won't affect it. You should probably take a look at what hcitool is doing when its stuck - it may be a bug in the process, which you could report to the developer, or it may be due to some bluetooth device not properly implementing the discovery protocols, which leads to problems, or, well, anything!
Keep Calm and Carry On
-
Why should that be dangerous? Windows updated here and there was a power failure. (Do not turn of your machine?) It just kept working.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Member 14968771 wrote:
How safe or dangerous would it be to stop and restart the Linux Bluetooth service itself ?
It should not affect the running of the Linux system at all. It might leave any connected bluetooth devices "orphaned", I.E. with a connection that the kernel doesn't know about, but I really do not know. You almost certainly can't damage the linux system beyond needing a reboot to get back to where you were, so if I were you I'd try it and see what effect it has. In particular I'd look to see if currently connected devices keep working, and if the stuck process recovers quickly after the restart. I suspect that restarting the service won't affect the stuck hcitool process. It probably has all it needs to do its work, so restarting the bluetooth service won't affect it. You should probably take a look at what hcitool is doing when its stuck - it may be a bug in the process, which you could report to the developer, or it may be due to some bluetooth device not properly implementing the discovery protocols, which leads to problems, or, well, anything!
Keep Calm and Carry On
All sounds reasonably safe. I am sure you are correct - I should look into how hcitool scan is implemented. This is something I will never understand - Bluetooth is "implemented " in Linux kernel. It uses "blueZ" "stack"... "blueZ" source code is "available" in several versions and ALL of them are lacking code comments or function descriptions ... basically a code nobody maintains... My Linux version runs a "bluetooth manager " and my QT implementation of "blueZ" library interact with this flaky manager - perhaps by using the Linux " blueZ stack "... That is why I asked "Bluetooth service " .... BTW can you tell what the hell is "stack"? I had some fun in haystack(s) in my youth...
-
All sounds reasonably safe. I am sure you are correct - I should look into how hcitool scan is implemented. This is something I will never understand - Bluetooth is "implemented " in Linux kernel. It uses "blueZ" "stack"... "blueZ" source code is "available" in several versions and ALL of them are lacking code comments or function descriptions ... basically a code nobody maintains... My Linux version runs a "bluetooth manager " and my QT implementation of "blueZ" library interact with this flaky manager - perhaps by using the Linux " blueZ stack "... That is why I asked "Bluetooth service " .... BTW can you tell what the hell is "stack"? I had some fun in haystack(s) in my youth...
A "stack" is the set of programs and/or system services needed to supply a given end-user (in this case) service. As I understand it, for bluez there's User programs : e.g. hcitool System software : e.g. whatever system processes are needed to monitor/provide bluetooth services System libraries : e.g. libbluetooth this provides interfaces for both system and user programs Kernel module : e.g. bluetooth module, which provides the kernel side implementation details As you can see, this forms a "stack", with each layer needing services from the layer below it to provide the services it needs to the layer above.
Keep Calm and Carry On