#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 (6)
comment:1 Changed 2 years ago by
Priority: | major → critical |
---|---|
Status: | new → assigned |
comment:2 Changed 2 years ago by
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
comment:3 Changed 2 years ago by
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:6 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2181
Unsetting the dbus env vars does not help:
But this does:
So it must be some other env var?