Removing Bluetooth device doesn't remove cache

REGRESSION: no (probably)


Removing paired Bluetooth device doesn’t remove cache item from /var/lib/bluetooth/cache which can lead to confusion.


  • Have two identical handsfrees at hand


  1. Power on and pair handsfree 1
  2. Make a call and use the handsfree to see it works OK
  3. Shut down handsfree 1
  4. Remove handsfree 1 from paired devices
  5. Power on and pair handsfree 2
  6. Make a call and use the handsfree to see if it works


  1. No remnants of handsfree 1 in /var/lib/bluetooth/cache
  2. The device works as expected


  1. Obsolete cache item in /var/lib/bluetooth/cache
  2. The call is router to handsfree
  3. It works for a second or two, then disconnects
  4. The Bluetooth device is connected but the call can’t be routed to it


After step 5) there are two files in /var/lib/bluetooth/cache folder with different MAC addresses and same name (tested with JBL TUNE750BTNC). Removing device 2 and re-pairing it doesn’t fix the issue.

I fixed the issue by removing all Bluetooth devices, turning off Bluetooth, clearing all files from the cache dir, powering on Bluetooth and pairing the device once again. Removing only the device may well be enough though, I just didn’t bother grepping the files using the on screen keyboard.

This is likely not a regression but a long time bug. I remember hitting the same bug (or close) in Sailfish 3.x and clearing the cache did the trick.

An educated but still blind suggestion: purge the cache directory of non-paired devices when Bluetooth is turned on.



Good possible that this is a bluetooth (bluez5) issue unrelated to SFOS version

Jolla-internal bug filed about this. It is a healthy principle to delete the data related to an object after it was removed.


Couldn’t the watchdog service do this?

1 Like

Does setting the caching option to yes help? IIRC off doesn’t work.

GitHub - atx/AsteroidOSLinux: AsteroidOS Linux control application This is what I was running when it broke for my watch, which is further compounding the issue for me…

The device cache file is still not removed when the device pairing is removed on

cache files are still not removed on ( the cache path is /var/lib/bluetooth/xx:xx:xx:xx:xx:xx/cache where xx:xx:xx:xx:xx:xx is the BT mac address of the phone)
I had to manually remove “orphan” entries for the phone to work again with the car.
Otherwise the car was displaying empty ("") phone name after pairing and connection would work only once. For it to re-connect I had to remove pairing on both car and phone then re-pair

unfortunately this is how the linux bluetooth stack is working. I am not sure if this request is here at the right place and if someone would take care of filing your request to the bluez development team.

Is there a rule to know which cache files are orphans?

One could write a script and systemd service to clean them. Or add the function to SF Utilities.

1 Like

Yes, please add this function to SF-Utilities!

But you can not request something like this in that way. If it works for you, it doesn’t mean it is good for me. Perhaps sometimes this cache is needed and reused. I do not think this or the other is the better way. May be there should be an option to remove cache if desired, when you delete the device and you decide what to do with the cache.

just 5c on that

I experienced a same behaviour with a deleted company WLAN-Accesspoint. After removing the white dot (enable/disable) it comes up and connected next time. Then i use the “Forget Network”, still the same. I had to do it at home, then it worked.

As this is related to wifi, it would be good if you could create a new bug report about this

Yes, i know. But this Issue comes until today one time, so i don´t know how to retrigger it, its needed to file a new bug report, indeed.

1 Like