totaam
commented
1 year ago
unix:abstract=/tmp/dbus-WKWASbKtkQ,guid=23bc01b472ca9ec2a571051963c7bf07I do not understand where this address comes from
By default, xpra will use dbus-launch to start a new dbus daemon and configure the environment of the xpra session to point to it.
This can be turned off with the --dbus-launch=no command line option.
That's why you should always launch applications with xpra --start=app or indirectly via a terminal launched using --start=, and not using DISPLAY=:NUMBER app.
I have a good guess; of
--dbus-proxy, it sounds like it sets some kind of dbus endpoint (terminology?)
This allows the xpra client to forward some dbus calls to the dbus session running on the server. This is rarely used and never needed.
It's also not clear to me if
--dbus-controllistens on the client or server side...
Server side.
Observe that the user dbus service is running and the socket is there:
That's not the one that should be used by the xpra session.
Observe that setting
DBUS_SESSION_BUS_ADDRESSto point to this socket fixes the issue:
This should be avoided as this will pollute your desktop's dbus session with the applications running in your xpra sessions, potentially creating conficts, and definitely causing problems for the applications using dbus in your xpra session if your main desktop session is terminated before them.
after that the same xpra command causes the terminal window to appear on the "physical" screen of the server
I'm not sure I understand / guess the commands involved.
Some applications like browsers and some Gnome applications will launch new windows / tabs on the same display as the first instance launched instead of honouring the DISPLAY environment variable. That's a "feature" they say.
As to your overall question about dbus, I would advise you to use a different distribution to avoid such problems. I don't see these problems on Fedora, but then again, I don't use snap either..
sliedes
Describe the bug
Connecting to a Ubuntu Jammy Jellyfish (22.04.1 LTS) machine, somehow the dbus settings go wrong (or right, but do not support this use case?), preventing e.g. snap programs such as firefox and chrome from starting. Most other programs still seem to work, and I don't quite understand what snap is doing here and if the environment as set by xpra is somehow incorrect.
To Reproduce
Steps to reproduce the behavior:
xpra start ssh://sli-gpu/99 --start=gnome-terminal --keyboard-raw=yes --input-method=keep --splash=nofirefox/user.slice/user-1000.slice/session-54.scope is not a snap cgroup. Nothing is output on the client side with -d dbus.DBUS_SESSION_BUS_ADDRESSis set to a value that does not point to the "user session socket", as far as I understand it (this may be intentional on xpra's side; I don't understand the internals nor have found documentation):I do not understand where this address comes from, nor do I understand xpra and dbus deeply enough to have figured it out yet. I have tried all xpra's dbus related options (
--dbus-launch=no,--dbus-proxy=yes|no,--dbus-control=yes|no), but nothing helped.FWIW, I haven't been able to figure out using the xpra documentation what those switches exactly are for. Of
--dbus-launch, I have a good guess; of--dbus-proxy, it sounds like it sets some kind of dbus endpoint (terminology?) on the client side and forwards it to the server "somehow", but I do not understand the implications of this or what it would be used for or how it should impact the bus used. It's also not clear to me if--dbus-controllistens on the client or server side... (I might send a documentation patch if I figure these out.)DBUS_SESSION_BUS_ADDRESSto point to this socket fixes the issue:... but, again, I do not understand the implications of running it in the user dbus session instead of the one set up(?) by xpra.
In case it's useful information, if I connect to an Arch xpra server v4.3.3-r0 with the same command line on the same client,
DBUS_SESSION_BUS_ADDRESSis set to a slightly different looking value ofunix:path=/tmp/dbus-ThUwuEVKKU,guid=0f5cd6819b4e39f39e274b5463c7c2b4, i.e. it lives in the filesystem (unix:path instead of unix:abstract). I do not have snap on this server, so I don't know if it would work.System Information (please complete the following information):
setxkbmap se -variant dvorak; mentioning as this is unusual (it's also the reason I landed on --keyboard-raw=yes --input-method=keep; only with those everything seems to work for me).Additional context
My xpra.conf:
For completeness, the error messages printed by starting firefox after setting DBUS_SESSION_BUS_ADDRESS:
xpra debug output:
An observation that may be related, non-related, another bug or a non-bug: I noticed that if I have logged in to the server from gdm (or whatever the display manager is on standard installation of Ubuntu), to the standard wm of Ubuntu (is it still unity?), after that the same xpra command causes the terminal window to appear on the "physical" screen of the server. Inspecting its environment, it still says
DISPLAY=:99, and starting non-gnome programs from it, such asxev, causes them to be forwarded to the client side.Output from
xpra showconfig:server.log:
xpra-info full output; here's the parts that are, to me, not clearly about something else: