dbus failure with python3

[totaam]

Issue migrated from trac ticket # 2181

component: server | priority: critical | resolution: fixed

2019-02-28 11:13:54: antoine created the issue

---

Not sure what the problem is, the output looks identical to the python2 server, but then:

2019-02-28 17:53:34,184 org.xpra.Server(<server.XpraServer object at 0x7f66e6ceafc0 (xpra+x11+server+XpraServer at 0x55a654a6fb80)>)
2019-02-28 17:53:34,184 dbus_exception_wrap() <bound method XpraServer.make_dbus_server of <server.XpraServer object at 0x7f66e6ceafc0 (xpra+x11+server+XpraServer at 0x55a654a6fb80)>>()=<xpra.x11.dbus.x11_dbus_server.X11_DBUS_Server at /org/xpra/Server at 0x7f66e2ac9cf8>
2019-02-28 17:53:34,185 init_notification_forwarder() enabled=True
2019-02-28 17:53:34,185 init_notification_forwarder()
Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/server/mixins/notification_forwarder.py", line 64, in init_notification_forwarder
    self.notifications_forwarder = register(self.notify_callback, self.notify_close_callback)
  File "/usr/lib64/python3.7/site-packages/xpra/dbus/notifications_forwarder.py", line 180, in register
    raise Exception("the name '%s' is already claimed on the session bus" % BUS_NAME)
Exception: the name 'org.freedesktop.Notifications' is already claimed on the session bus
2019-02-28 17:53:34,186 Warning: cannot forward notifications,
2019-02-28 17:53:34,186  the interface is already claimed
2019-02-28 17:53:34,186  if you do not have a dedicated dbus session for this xpra instance,
2019-02-28 17:53:34,186  use the 'notifications=no' option

It's using the old dbus attributes from my local session rather than the ones it gets from the dbus-launch.

[totaam]

2019-02-28 11:50:15: antoine changed priority from major to critical

[totaam]

2019-02-28 11:50:15: antoine changed status from new to assigned

[totaam]

2019-02-28 11:50:15: antoine commented

---

Unsetting the dbus env vars does not help:

DBUS_SESSION_BUS_ADDRESS= DBUS_SESSION_BUS_PID= DBUS_SESSION_BUS_WINDOWID= python3 /usr/bin/xpra start ..

But this does:

env -i python3 /usr/bin/xpra start ..

So it must be some other env var?

[totaam]

2019-02-28 15:23:00: antoine commented

---

Identified the first variable that causes a problem by dumping the environment from a regular shell and then from env -i bash, then gradually adding variables until problems occur.

First up, DBUS_SESSION_BUS_ADDRESS, which is weird because we override it with the value we get from dbus-launch, as seen in the debug output as of r21908:

init_dbus_server() dbus_control=True
init_dbus_server() env: {'DBUS_SESSION_BUS_ADDRESS': 'unix:abstract=/tmp/dbus-t5KPwbTjZx,guid=b5292dc9f10fad12629bc3b75c77ee94', \
    'DBUS_SESSION_BUS_PID': '30686', 'DBUS_SESSION_BUS_WINDOWID': '2097153'}

Anyway, running like this no longer fails from env -i bash:

DBUS_SESSION_BUS_ADDRESS="" xpra start ..

But there's more... XDG_RUNTIME_DIR also does something, but only with python3!?

---

There must be something else at play because this works with both python2 and python3:

env -i dbus-launch python3  ./xpra/dbus/notifications_forwarder.py 

And both fail when run using:

dbus-launch python3  ./xpra/dbus/notifications_forwarder.py 

See also #2198

[totaam]

2019-03-13 02:24:08: antoine commented

---

Added the simplest of test cases in r22063.
Then moved that same code around the server startup code and narrowed it down to:

• importing xpra.platform.gui
• which imports xpra.gtk_common.gtk_util
• which imports gtk..

So we have to wait until dbus is initialized before we can call anything that imports gtk. But we try to save the vfb pid to the display using gtk before that...

[totaam]

2019-03-13 03:23:57: antoine changed status from assigned to closed

[totaam]

2019-03-13 03:23:57: antoine set resolution to fixed

[totaam]

2019-03-13 03:23:57: antoine commented

---

Fixed in r22064.

[totaam]

2019-03-13 06:02:07: antoine commented

---

Fixup in r22071.