Blueman-applet crash on login: DBusException in call_blocking(): org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.bluez': timed out

[flexiondotorg]

This bug has been reported downstream. It affects Blueman 2.0.3 in Ubuntu MATE and Xubuntu 16.04. The issue manifests on computers where Bluetooth is disabled or not present.

• https://bugs.launchpad.net/ubuntu/+source/blueman/+bug/1533206
• https://bugs.launchpad.net/ubuntu/+source/blueman/+bug/1538409

I see there has been a lot of development of late. Is there a commit that might resolve this?

[flexiondotorg]

This log is taken from ~/.xession-errors.

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 175, in activate_name_owner
    return self.get_name_owner(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 361, in get_name_owner
    's', (bus_name,), **keywords)
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'org.bluez': no such name

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/blueman-applet", line 120, in <module>
    BluemanApplet()
  File "/usr/bin/blueman-applet", line 62, in __init__
    self.Plugins.Load()
  File "/usr/lib/python3/dist-packages/blueman/main/PluginManager.py", line 90, in Load
    __import__(self.module_path.__name__ + ".%s" % plugin, None, None, [])
  File "/usr/lib/python3/dist-packages/blueman/plugins/applet/DBusService.py", line 12, in <module>
    from blueman.main.applet.BluezAgent import AdapterAgent
  File "/usr/lib/python3/dist-packages/blueman/main/applet/BluezAgent.py", line 20, in <module>
    from blueman.bluez.Agent import Agent, AgentMethod
  File "/usr/lib/python3/dist-packages/blueman/bluez/Agent.py", line 48, in <module>
    class Agent(dbus.service.Object):
  File "/usr/lib/python3/dist-packages/blueman/bluez/Agent.py", line 56, in Agent
    @AgentMethod
  File "/usr/lib/python3/dist-packages/blueman/bluez/Agent.py", line 38, in AgentMethod
    if BlueZInterface.get_interface_version()[0] < 5:
  File "/usr/lib/python3/dist-packages/blueman/bluez/BlueZInterface.py", line 16, in get_interface_version
    obj = dbus.SystemBus().get_object('org.bluez', '/')
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 241, in get_object
    follow_name_owner_changes=follow_name_owner_changes)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 248, in __init__
    self._named_service = conn.activate_name_owner(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 180, in activate_name_owner
    self.start_service_by_name(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 278, in start_service_by_name
    'su', (bus_name, flags)))
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.bluez': timed out

[cschramm]

I've seen that before. If I remember correctly it's related to systemd which removes the service configuration for org.bluez if one disables bluetooth.service. blueman needs to be prepared for that situation.

[flexiondotorg]

Is a trivial fix possible or is this a non-trivial issue?

[cschramm]

I'm not sure about 2.0, but it should be quite simple in current master: We probably just need to catch an exception in blueman/bluez/Base.py:63, but it's an odd situation and the question would be what to do after catching it. Show a message dialog? Terminate?

There are basically two ways blueman-applet could get invoked:

• Either automatically when a desktop session is started - this is the usual way and typically done by the maintainer by installing /etc/xdg/autostart/blueman.desktop
• or manually by the user.

In the later case I'd definitely expect a message or crash if the BlueZ service is not available (no matter if it's not installed or disabled by systemd, we cannot really distinguish anyway). If the user decides to disable bluetooth in systemd, it does not make sense to show this message on every session start of course. Ideally blueman-applet would get removed from autostart then. This could be achieved by installing it as a systemd user service that depends on the bluetooth service. However, that's an isolated solution for systemd again...

I'm really not sure how to deal with this. The best solution is probably the saying-"keep your systemd problems, we do not care"-to-the-user one. 😉

[flexiondotorg]

I think a silent terminate would be preferable to a crash. Most distributions trap crashes to allow for bug reporting, currently every computer without Bluetooth or with Bluetooth disabled triggers a crash report at login for Ubuntu MATE, Xubuntu and Lubuntu.

[infirit]

We only get there because we try to detect the bluez version so perhaps we don't need to do anything in master. This untested patch may be enough to make it work? I'll try it on a 16.04 vm later.

[cschramm]

It just happens as soon as we try to use the bus. That should always be Base.py:63 in master. In 2-0-stable it's the version detection, yes.

[Lanchon]

can't there be a startup argument meaning "silently exit if you can't find the daemon" that autostarting can use?

but this will fail if the daemon is later installed: the applet won't be available until the applet container is restarted.

what is really needed is either of:

• make the applet 'work' without the daemon in some kind of idle mode that will detect when the daemon comes up and start using it. this mode could be disabled by default and only enabled via a switch.
• make systemd manage the applet's life when dependencies are met. yes, it is a systemd-only solution but i don't see a problem: it's the distro's chosen solution to these kinds of problems.

[cschramm]

make the applet 'work' without the daemon in some kind of idle mode that will detect when the daemon comes up and start using it.

Thought about that as well, but I think it would be a whole lot of work.

make systemd manage the applet's life when dependencies are met. yes, it is a systemd-only solution but i don't see a problem: it's the distro's chosen solution to these kinds of problems.

systemd is the problem here as it removes essential files of installed packages.

I don't have a problem with fixing systemd issues with systemd solutions, but I'm not sure how systemd service vs. xdg autostart works out. I think you must not install both configurations as the application would be started twice in systemd environments then. So the user has to choose between systemd or xdg autostart during configure, but this does not work e.g. for Debian where different init systems may be used. I'll check how it's handled for other applications with similar situations.

[Lanchon]

well i guess that:

• if systemd is controlling services
• and desktop components can require optional services

then there should be a desktop-wide solution to bring desktop components up and down according to systemd's mandates; something that replaces xdg autostart.

but quick googling didn't produce results. bubbling up the impedance mismatch between systemd and desktop to the application world (ie: apps cannot depend on services being there) is not a solution: it's the absence of one.

it is really not your responsibility: the system should not be starting your applet without fulfilling its dependencies. the addition of an 'idle mode' means a lot of code, no just to your applet but potentially to all applets, just to workaround a defective system configuration. better not do it (unless it's trivial).

but the hackish --silent-death-if-no-daemon option could help maintainers for the time being. if you manually bring up the bt service after bootup, it's not the end of the world to have to manually start blueman.

[infirit]

It just happens as soon as we try to use the bus.

Forcing the version per my patch actually worked surprisingly well. We fail in a couple of plugins and my guess is that we do too much in on_load which we probably need to move to on_manager_state_changed.

[cschramm]

I have a temporary patch for 2-0-stable in cschramm/blueman@f5eae36. The fallback in get_interface_version is what Ubuntu does to get this resolved, however we cannot actually do this upstream as we assume BlueZ 5 then. The additional introspect=False fixes unimportant error messages from asynchronous introspection calls.

A similar patch for master is in cschramm/blueman@a445a6a, but it needs more work. Registering the obexd agent fails due to the missing introspection (it works fine in 2-0-stable).

[AnwarShah]

What's the current status of it? It's still a major issue

[cschramm]

It looks like this is fixed in master, probably by #679. Can anybody confirm that?