dbus issues when connecting to Ubuntu, breaking e.g. snap #3740
Comments
By default, xpra will use
This allows the xpra client to forward some dbus calls to the dbus session running on the server.
Server side.
That's not the one that should be used by the xpra session.
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.
I'm not sure I understand / guess the commands involved. 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 |
Thanks for the explanations, this already clarifies quite a bit!
Yes, I figured out that's most likely what's happening here. This only happens, though, if I have logged in physically in that machine, and I generally don't need to do that.
That would certainly be a solution. I guess I can read this as you not having much insight on what might go wrong here with snap, and probably not much motivation to figure out. I can sympathize with that, especially seeing that Ubuntu has generated quite a bit of grief for xpra. Huh, I forgot to attach the error message printed by There's some discussion of something probably closely related here, which I understand like 50%: https://forum.snapcraft.io/t/cannot-launch-snap-applications-with-cgroup-v2/27700 "Snap run attempts to create a separate scope (a cgroup actually) for the application by talking to org.freedesktop.systemd1.Manager over session bus. In your case, the session bus is unavailable, so a separate cgroup cannot be created thus it is not possible to set up device access rules or identify processes belonging to a snap." In our case, it's not unavailable, but I guess that systemd1.Manager might not be there? But I haven't figured out what should create that, i.e. if the session needs to be created in some specific way (--systemd-run=yes certainly doesn't help with this). |
@sliedes Try starting your server with |
|
Closing as there are not issues with tier-1 platforms: https://github.com/Xpra-org/xpra/wiki/Platforms |
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:
The text was updated successfully, but these errors were encountered: