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
.
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?
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
Added the simplest of test cases in r22063. Then moved that same code around the server startup code and narrowed it down to:
xpra.platform.gui
xpra.gtk_common.gtk_util
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...
Fixed in r22064.
Fixup in r22071.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2181