Blueman freezes before it starts

[heit0r]

blueman: blueman-manager v2.4.1 BlueZ: bluez 5.75 Distribution: Linux A410 6.8.9-3-MANJARO #1 SMP PREEMPT_DYNAMIC Thu May 9 18:25:19 UTC 2024 x86_64 GNU/Linux Desktop environment: XFCE 4.18

• [✔] I have consulted the Troubleshooting page and done my best effort to follow.

When I click in blueman on system tray (also from the menu), the window just pops up with a title bar and a not clickable freeze content. After 30 seconds everything appears as it should and works as usual but sometimes, like now, the Search button is grayed out and I cannot search for devices. I'm also getting this message over and over again when I open blueman-manager:

"Failed to reach blueman-manager

It seems that blueman-manager could not be activated via D-BUS. A typical cause for this is a graphical broken setup in the D-BUS activation environment that can get resolved with a call to dbus-update-activation-environment, typically issued from xinitrc (respectively the Sway config or similar)"

A log can be seen here: https://pastebin.com/ZFUEV44L And it's possible to see that it works completely normal after it starts, by discovering a lot of mac addresses and so on.

Thank you.

1. Frozen window:

2. Warning after 30 seconds of frozen window:

3. Everything works:

[Krakonos]

I see the same behavior on Arch Linux. I actually noticed that a few weeks ago, but fixed that by downgrading to blueman-manager 2.3.5. However, due to Python bump that is no longer an easy option so I'm stuck with 2.4.1

The interesting thing is that it seems to work after the error - it shows the connected devices, but actions are sluggish and tend to timeout with the same issue again.

[KeanuGh]

Same issue also on arch linux

[cschramm]

@Krakonos and @KeanuGh on XFCE as well?

[KeanuGh]

@cschramm cinnamon for me

[infirit]

I'm setting up a manjaro xfce4 vm to see if I can reproduce.

[cschramm]

@infirit: Does not seem generic. 2.4.1 works fine for me with Cinnamon and Arch.

[infirit]

@infirit: Does not seem generic. 2.4.1 works fine for me with Cinnamon and Arch.

Yup, can't reproduce with a fresh manjaro xfce4 vm :thinking:

[KeanuGh]

just to add my error is the same in the logs (at the time that the window eventually pops up):

blueman-applet 15.14.04 ERROR    DBusProxies:62 activate  : Call to org.blueman.Manager failed
Traceback (most recent call last):
  File "/usr/lib/python3.12/site-packages/blueman/main/DBusProxies.py", line 57, in activate
    self.call_sync("Activate", param, Gio.DBusCallFlags.NONE, -1, None)
gi.repository.GLib.GError: g-io-error-quark: Timeout was reached (24)

[Krakonos]

@cschramm i3 . I activate dbus using standard /etc/X11/xinit/xinitrc.d/50-systemd-user.sh from .xsession. No issues there.

Since it doesn't seem reproducible, is there a cache/config that could be from an old version and may interfere? Though I was under the impression all relevant config is stored in bluez.

[cschramm]

There is /var/lib/blueman/network.state, GSettings, but nothing that I'd expect to cause something like that.

When starting blueman-manager manually it works fine?

blueman-manager error logs from D-Bus activation should be visible with journalctl -f.

Can you reproduce with 2.4-2 or the blueman-git AUR package?

[KeanuGh]

just tried with blueman-git but it didn't solve the issue

[heit0r]

Thanks everyone for all your replies.

When starting blueman-manager manually it works fine?

THIS!! So the problem might be in the blueman app in the system tray. By starting it from the terminal, the window just pop up normally and works fine. I'm just getting these gtk messages, but it seems not to be important:

$ blueman-manager 

(blueman-manager:1224): Gtk-CRITICAL **: 13:35:47.943: _gtk_css_image_get_concrete_size: assertion 'default_width > 0' failed

(blueman-manager:1224): Gtk-CRITICAL **: 13:35:47.943: _gtk_css_image_get_surface: assertion 'surface_height > 0' failed

(blueman-manager:1224): Gtk-CRITICAL **: 13:35:47.945: _gtk_css_image_get_concrete_size: assertion 'default_width > 0' failed

(blueman-manager:1224): Gtk-CRITICAL **: 13:35:47.945: _gtk_css_image_get_surface: assertion 'surface_height > 0' failed

blueman-manager error logs from D-Bus activation should be visible with journalctl -f.

I've got some error messages (still from blueman 2.4.1): https://pastebin.com/XA3ccnhA

Can you reproduce with 2.4-2 or the blueman-git AUR package?

Yes. I've just installed it from blueman-git. But after compile and install everything, the behavior of the blueman system tray remains the same. I'm also getting the "Search 🔍" button greyed out and missing from the Adapter dialog¹, which was also happening with blueman 2.4.1. Only after rebooting the machine (closing session doesn't work) it comes back no normal as it should be². To summarize, the behavior of blueman-git stays exactly the same as blueman v2.4.1 here.

Here the output of 'journalctl -f' of the new version by starting it from the tray: https://pastebin.com/uAQsFuVk

The output from 'blueman-applet --loglevel debug' in the new version: https://pastebin.com/wLhLXeF6

1. After connecting and disconnecting, trying to grab error messages and etc:

2. After reboot, everything comes back to normal:

I don't know if it has something to do with this issue, but i'm also getting error messages from dmesgthat I'm not sure what means by error -110. Didn't find anything online. But I think this is an OS level issue. Here they are anyway:

# dmesg | grep Bluetooth
[    1.569831] usb 2-1.2: Product: Bluetooth Radio
[    7.770377] Bluetooth: Core ver 2.22
[    7.770419] Bluetooth: HCI device and connection manager initialized
[    7.770426] Bluetooth: HCI socket layer initialized
[    7.770433] Bluetooth: L2CAP socket layer initialized
[    7.770442] Bluetooth: SCO socket layer initialized
[    8.158618] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761
[    8.159616] Bluetooth: hci0: RTL: rom_version status=0 version=1
[    8.159625] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin
[    8.161721] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin
[    8.162667] Bluetooth: hci0: RTL: cfg_sz 6, total sz 30210
[    8.324613] Bluetooth: hci0: RTL: fw version 0xdfc6d922
[    8.440774] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[    8.440784] Bluetooth: BNEP filters: protocol multicast
[    8.440793] Bluetooth: BNEP socket layer initialized
[    8.445424] Bluetooth: MGMT ver 1.22
[   27.250622] Bluetooth: RFCOMM TTY layer initialized
[   27.250639] Bluetooth: RFCOMM socket layer initialized
[   27.250645] Bluetooth: RFCOMM ver 1.11
[   29.421128] Bluetooth: hci0: Opcode 0x0c24 failed: -110
[   29.421158] Bluetooth: hci0: command 0x0c24 tx timeout
[   31.554540] Bluetooth: hci0: Opcode 0x0c24 failed: -110
[   31.554600] Bluetooth: hci0: command 0x0c24 tx timeout

But it works perfectly without disconnections or artifacts in audio:

$ hciconfig -a
hci0:	Type: Primary  Bus: USB
	BD Address: 00:E0:4C:7E:5E:03  ACL MTU: 1021:6  SCO MTU: 255:12
	UP RUNNING 
	RX bytes:292176 acl:64 sco:0 events:41340 errors:0
	TX bytes:27759923 acl:41017 sco:0 commands:307 errors:0
	Features: 0xff 0xff 0xff 0xfe 0xdb 0xfd 0x7b 0x87
	Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
	Link policy: RSWITCH HOLD SNIFF PARK 
	Link mode: PERIPHERAL ACCEPT 
	Name: 'RTK_BT_5.0'
	Class: 0x6c010c
	Service Classes: Rendering, Capturing, Audio, Telephony
	Device Class: Computer, Laptop
	HCI Version: 5.1 (0xa)  Revision: 0xdfc6
	LMP Version: 5.1 (0xa)  Subversion: 0xd922
	Manufacturer: Realtek Semiconductor Corporation (93)

From ìnxi -Fxxxz. Working fine:

Bluetooth:
  Device-1: Realtek Bluetooth Radio driver: btusb v: 0.8 type: USB rev: 1.1
    speed: 12 Mb/s lanes: 1 bus-ID: 2-1.2:3 chip-ID: 0bda:8771 class-ID: e001
    serial: <filter>
  Report: hciconfig ID: hci0 rfk-id: 0 state: up address: <filter> bt-v: 5.1
    lmp-v: 10 sub-v: d922 hci-v: 10 rev: dfc6 class-ID: 6c010c

Sorry for the long reply and thanks in advance.

[Krakonos]

Right, launching blueman-manager from the commandline shows up the window immediately and it seems to work just fine. Closing and reopening from the tray icon times out.

The same issue with latest arch build and -git AUR package too.

[Krakonos]

I don't know if it has something to do with this issue, but i'm also getting error messages from dmesgthat I'm not sure what means by error -110. Didn't find anything online. But I think this is an OS level issue.

I don't see any hci related errors in kernel, so it likely isn't related.

[cschramm]

Thanks for all the input.

Did anybody try 2.4-2? I noticed that @Antiz96 switched to a source tarball for 2.4.1 and running ./autogen.sh for the package and wonder if that might be causing some issue.

blueman-applet most probably is not to blame. You should see similar results with any D-Bus-activated instance of blueman-manager, e.g. triggering it with dbus-send --print-reply --dest=org.blueman.Applet /org/blueman/Applet org.blueman.Applet.Activate. What could be, though, is that blueman-applet waits for blueman-manager and blueman-manager waits for blueman-applet which does not reply while it's waiting. That would actually restrict the issue to activation from blueman-applet.

From the 30 seconds freeze, I'd say that blueman-manager is waiting for some D-Bus reply itself until it times out. I'm surprised that there wouldn't be anything from blueman-manager in the journal. Those who are adventurous could try to find something on the bus, e.g. in dbus-monitor --session sender=org.blueman.Manager destination=org.blueman.Manager. After initial "noise" there might just be the problematic method call followed by 30 seconds of nothing.

[Antiz96]

Hi everyone :wave:

Did anybody try 2.4-2?

2.4-2 is only a rebuild against python 3.12, no change were made about the package itself (compared to 2.4-1).

I noticed that @Antiz96 switched to a source tarball for 2.4.1 and running ./autogen.sh for the package and wonder if that might be causing some issue.

Indeed, I switched to the auto-generated source tarball to use a more transparent source for the package (c.f. xz situation), which is why ./autogen.sh is run now (which is not necessary with the custom .tar.xz archive uploaded a release asset as far as I know).

For what it's worth, 2.4.1 works perfectly on my side. I don't experience such freezes (both with i3 and Sway on Arch). Still, I rebuilt a package using the custom .tar.xz archive uploaded a release asset so we can verify if the switch to the source tarball is to blame here. It is available here. Can someone using Arch and experiencing the freeze issue can give it a try?

[infirit]

blueman-applet most probably is not to blame. You should see similar results with any D-Bus-activated instance of blueman-manager, e.g. triggering it with dbus-send --print-reply --dest=org.blueman.Applet /org/blueman/Applet org.blueman.Applet.Activate. What could be, though, is that blueman-applet waits for blueman-manager and blueman-manager waits for blueman-applet which does not reply while it's waiting. That would actually restrict the issue to activation from blueman-applet.

From the 30 seconds freeze, I'd say that blueman-manager is waiting for some D-Bus reply itself until it times out. I'm surprised that there wouldn't be anything from blueman-manager in the journal. Those who are adventurous could try to find something on the bus, e.g. in dbus-monitor --session sender=org.blueman.Manager destination=org.blueman.Manager. After initial "noise" there might just be the problematic method call followed by 30 seconds of nothing.

My guess is we do a blocking call somewhere in the chain and timeout. I have made the activate method on the ManagerService dbus proxy asynchronous in #2384. With this the applet should be able to respond to requests from blueman-manager. Would be nice if some one can check if this helps.

Still weird only some folks are hitting this.

[heit0r]

blueman-applet most probably is not to blame. You should see similar results with any D-Bus-activated instance of blueman-manager, e.g. triggering it with dbus-send --print-reply --dest=org.blueman.Applet /org/blueman/Applet org.blueman.Applet.Activate. What could be, though, is that blueman-applet waits for blueman-manager and blueman-manager waits for blueman-applet which does not reply while it's waiting. That would actually restrict the issue to activation from blueman-applet. From the 30 seconds freeze, I'd say that blueman-manager is waiting for some D-Bus reply itself until it times out. I'm surprised that there wouldn't be anything from blueman-manager in the journal. Those who are adventurous could try to find something on the bus, e.g. in dbus-monitor --session sender=org.blueman.Manager destination=org.blueman.Manager. After initial "noise" there might just be the problematic method call followed by 30 seconds of nothing.

My guess is we do a blocking call somewhere in the chain and timeout. I have made the activate method on the ManagerService dbus proxy asynchronous in #2384. With this the applet should be able to respond to requests from blueman-manager. Would be nice if some one can check if this helps.

Still weird only some folks are hitting this.

Unfortunately, the issue persists. Just installed @Antiz96 version and now when I run blueman-manager from the applications menu, the blueman window pops up with no warnings and no delay. If I'm not mistaken, starting the previous version up from the applications menu still incurred in delay and warning.

But the issue persists by starting it up from the system tray anyway, with the same delay and the same warning. Here's another log with the outputs from blueman-applet --loglevel debug and journalctl -f https://pastebin.com/sbZW9rCA

You version has just some broken icons. But after the 30s delay, it works as usual.

If I may provide any other info, please, let me know. Thank you so much.

[heit0r]

My guess is we do a blocking call somewhere in the chain and timeout. I have made the activate method on the ManagerService dbus proxy asynchronous in #2384. With this the applet should be able to respond to requests from blueman-manager. Would be nice if some one can check if this helps.

Still weird only some folks are hitting this.

Just switched to blueman-git and the issue persists only from the system tray, not from the app menu as I thought. Here's another log for starting it from the system tray: https://pastebin.com/XpyGBa9r

The icons came back to normal with the git version.

[Antiz96]

Unfortunately, the issue persists. Just installed @Antiz96 version and now when I run blueman-manager from the applications menu, the blueman window pops up with no warnings and no delay. If I'm not mistaken, starting the previous version up from the applications menu still incurred in delay and warning.

But the issue persists by starting it up from the system tray anyway, with the same delay and the same warning. Here's another log with the outputs from blueman-applet --loglevel debug and journalctl -f https://pastebin.com/sbZW9rCA

Ok so the source switch is not the cause apparently, right?

[KeanuGh]

Just to add I don't have any issue with broken icons or search being greyed out, so that may be a separate issue

[cschramm]

Ok so the source switch is not the cause apparently, right?

Seems like it, yes. Also blueman-git being affected as well is an argument against that. Nobody tried 2.4, though, but I clearly expect the same issue with it for those affected.

[Antiz96]

Ok so the source switch is not the cause apparently, right?

Seems like it, yes. Also blueman-git being affected as well is an argument against that. Nobody tried 2.4, though, but I clearly expect the same issue with it for those affected.

Alright thanks for the confirmation, I'm deleting my custom test package then. If anything, the 2.4 package is available here if anyone wanna try it ;)

[StragaSevera]

I have the same problem - the empty frozen window for 30 seconds, and after that it works OK. I can give you any logs and things like that if you need them.

[heit0r]

Alright thanks for the confirmation, I'm deleting my custom test package then. If anything, the 2.4 package is available here if anyone wanna try it ;)

I have no issues whatsoever with this 2.4 version. This completely solved my problem. No delay, no warnings, no greyed out icons, no nothing. And immediately triggered the update in the package manager.

The outputs of journalctl -f and blueman-applet --loglevel debug: https://pastebin.com/M2xLEFKp

[KeanuGh]

Alright thanks for the confirmation, I'm deleting my custom test package then. If anything, the 2.4 package is available here if anyone wanna try it ;)

So this is strange - I installed the package and it indeed started working as expected, but when I updated back up to 2.4.1-1, it still worked! It even still works again after a restart. I'm wondering now if a simple reinstall wouldn't have fixed it in the first place 😂

@StragaSevera can you try reinstalling the blueman package from your package manager to check if that fixes the issue?

[kuraga]

Don't forget to reboot after (re-)installing :)

By the way, I saw similar in 2.4.1 (https://github.com/blueman-project/blueman/issues/2318#issuecomment-2054186739, but #2322?) but haven't seen for a long time.

The same for https://github.com/blueman-project/blueman/issues/2332#issuecomment-2075401399.

[heit0r]

So this is strange - I installed the package and it indeed started working as expected, but when I updated back up to 2.4.1-1, it still worked! It even still works again after a restart. I'm wondering now if a simple reinstall wouldn't have fixed it in the first place 😂

@StragaSevera can you try reinstalling the blueman package from your package manager to check if that fixes the issue?

Indeed. It's strange how this issue doesn't affect everybody. All I can think it's maybe a configuration issue, something related to the window manager, maybe? @KeanuGh is using Cinnamon, which also comes from gnome, if I'm not mistaken. Maybe this tells something? Idk. If there is any other output I may provide, let me know everyone.

[heit0r]

I'm sorry. I thought my problems were solved with a downgrade, but I'm just experiencing the aforementioned issues right now.

[KeanuGh]

This issue also came back for me, for what it's worth