xpra icon
Bug tracker and wiki

Opened 4 weeks ago

Closed 12 days ago

Last modified 12 days ago

#2181 closed defect (fixed)

dbus failure with python3

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: critical Milestone: 2.5
Component: server Version: 2.4.x
Keywords: Cc:

Description

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.

Change History (5)

comment:1 Changed 4 weeks ago by Antoine Martin

Priority: majorcritical
Status: newassigned

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?

comment:2 Changed 4 weeks ago by Antoine Martin

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

Last edited 2 weeks ago by Antoine Martin (previous) (diff)

comment:3 Changed 12 days ago by Antoine Martin

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...

comment:4 Changed 12 days ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

Fixed in r22064.

comment:5 Changed 12 days ago by Antoine Martin

Fixup in r22071.

Note: See TracTickets for help on using tickets.