Troubleshooting running Xpra in docker container

[Simba98]

My host OS must be Ubuntu due to the program I want to run; by the way, it is a Qt-based program.
But the clipboard is not working, here is the test matrix.

Xpra Client	Xpra Client OS	Xpra Server	Xpra Server OS	Clipboard
5.0.2	Windows 11	4.4.6	CentOS 7	Work
5.0.2	Windows 11	5.0.2	CentOS 7	Work
5.0.2	Windows 11	5.0.2	CentOS 7 Docker	Failed
5.0.2	Windows 11	5.0.2	Fedora 37 VM	Work
5.0.2	Windows 11	5.0.2	Fedora 37 Docker	Failed
5.0.2	Windows 11	5.0.2	Ubuntu 20.04	Work

*: CentOS and Ubuntu are physical machines

As #3989, Ubuntu has Xdummy issue, so that I tried to build a xpra fedora container on the Ubuntu one, the dockerfile is attached in the end.
And run xpra start :23 -d clipboard --start=xterm in the Fedora docker.

From the log file, it seems like there is only an audio-related issue due to no D-bus in the docker. (Is D-bus the key point?)

So let's continue, run ssh -Y host command to connect to the target host.

However, the server log will throw paramiko.ssh_exception.AuthenticationException: Unable to connect to SSH agent.
OK, I just have a workaround: export SSH_AUTH_SOCK= (Is it OK? But seems like it should not related to clipboard...)

Now we can ssh -Y host to the target system and start the Qt-program.
When I try to copy something, the Qt-program will throw Qt Warning QXcbclipboard can not set x11 selection owner
However, the gedit is copy-paste fine.

By using xpra toolbox inside the xterm started by xpra, I do find some error output from xpra clipboard test tool.

/usr/lib64/python3.11/site-packages/xpra/client/gtk3/../../gtk_common/gtk_view_clipboard.py:196: DeprecationWarning: Gtk.Widget.modify_font is deprecated
  self.events.modify_font(fixed)
Traceback (most recent call last):
  File "/usr/lib64/python3.11/site-packages/xpra/client/gtk3/../../gtk_common/gtk_view_clipboard.py", line 149, in do_set_target
    self.clipboard.set_with_data([(target, 0, 0)], self.selection_get_callback, self.selection_clear_cb)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'Clipboard' object has no attribute 'set_with_data'
Traceback (most recent call last):
  File "/usr/lib64/python3.11/site-packages/xpra/client/gtk3/../../gtk_common/gtk_view_clipboard.py", line 90, in get_targets_callback
    self.get_targets.append_text(t)
TypeError: Must be string, not Atom
Traceback (most recent call last):
  File "/usr/lib64/python3.11/site-packages/xpra/client/gtk3/../../gtk_common/gtk_view_clipboard.py", line 149, in do_set_target
    self.clipboard.set_with_data([(target, 0, 0)], self.selection_get_callback, self.selection_clear_cb)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'Clipboard' object has no attribute 'set_with_data'
Traceback (most recent call last):
  File "/usr/lib64/python3.11/site-packages/xpra/client/gtk3/../../gtk_common/gtk_view_clipboard.py", line 149, in do_set_target
    self.clipboard.set_with_data([(target, 0, 0)], self.selection_get_callback, self.selection_clear_cb)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'Clipboard' object has no attribute 'set_with_data'

The full server log is attached in pastebin due to too long.
https://pastebin.com/kq3rb9mw

If the Xpra is running outside of docker, even some unsupported OS (e.g. CentOS 7 for Xpra 5), the clipboard works fine with Qt.
Do I have to get D-bus running inside the docker?

Thank you in advance and have a nice day.

Xpra Dockerfile:

FROM fedora

RUN curl -o /etc/yum.repos.d/xpra.repo https://xpra.org/repos/Fedora/xpra.repo ; \
    dnf -y update ;\
    dnf install -y openssh-server xpra openssh-clients gedit ;\
    dnf clean all

STOPSIGNAL SIGRTMIN+3
USER root
CMD ["/usr/sbin/sshd", "-D"]

[totaam]

Fedora 37 Docker | Failed

My initial guess would be that the packages installed are not the same, perhaps missing xpra-x11?

it seems like there is only an audio-related issue due to no D-bus in the docker.

This also points to the same problem. Your Docker installation probably installed the minimal packages and this did not include dbus...

However, the server log will throw paramiko.ssh_exception.AuthenticationException: Unable to connect to SSH agent.

Please include the full error message, preferably running the server with -d ssh.

AttributeError: 'Clipboard' object has no attribute 'set_with_data'

Looks like the clipboard tool need updating for Gtk API changes.

[totaam]

Are you saying that having all these extra packages installed did or did not fix the clipboard issue?
I don't know if the docker images somehow skip the Recommends type of dependencies or if somehow one of these extra dependencies is needed by your application.
You could try using the clipboard via xclip - this is as plain-X11 as can be.

[Simba98]

All these extra packages installed did not fix the clipboard issue.
My application is running outside of xpra docker, I always ssh from the xpra docker to the program machine. The program machine is Ubuntu and has the Xdummy issue so that is not suitable to execute xpra on it.
So, any package installed with or without xpra will not affect the Qt-program behavior.

xclip is always working and gedit is always working, only Qt-program will throw the Qt Warning: QXcbClipboard::setMimeData: Cannot set X11 selection owner error.

Thank you for getting back to me.

[totaam]

Perhaps these Qt applications are having problems with selection forwarding over ssh + xpra.
I would try without ssh to see if that changes anything.

[Simba98]

Perhaps these Qt applications are having problems with selection forwarding over ssh + xpra.

No, I can use CentOS7 SSH to the target Ubuntu machine and Fedora 38 VM SSH to the target Ubuntu machine.
Both are working as the test matrix on the top I showed.

[Simba98]

I do not want to waste your time so I just double-check it immediately.

Here is the result and both are SSH to the target machine in the same ssh command (SSH -Y USER@HOST -p PORT)

And also I tried to run on the Ubuntu docker directly, and mount /tmp/.X11-unix to share X11 socket to prevent the SSH, also it works.

Here is another test matrix.

Xpra server Env	Connection Method	Status
Fedora docker	X11 Socket Mounting	Failed
Fedora docker	SSH	Failed
Fedora docker with full Package Install	SSH	Failed
Fedora VM	SSH	Work
Ubuntu	X11 Socket Mounting	Work
CentOS	N/A, Same Machine	Work
CentOS Docker	SSH	Failed

[Simba98]

For the ssh agent, I added -d clipboard,ssh for both client and server.
The server log did not print any thing more, but client on MS Windows has the following outputs.

2023-09-18 12:06:44,883 Incoming forward agent connection
2023-09-18 12:06:44,884 [chan 5] Max packet in: 32768 bytes
2023-09-18 12:06:44,884 [chan 5] Max packet out: 16384 bytes
2023-09-18 12:06:44,885 Secsh channel 5 (auth-agent@openssh.com) opened.
Exception in thread Thread-6 (run):
Traceback (most recent call last):
  File "C:/msys64/mingw64/lib/python3.11/threading.py", line 1038, in _bootstrap_inner
  File "C:/msys64/mingw64/lib/python3.11/site-packages/paramiko/agent.py", line 145, in run
paramiko.ssh_exception.AuthenticationException: Unable to connect to SSH agent

I do not have any ssh agent on Windows, maybe I just simply disable this feature.
On windows,

ssh-add -l
Error connecting to agent: No such file or directory

And an interesting phenomenon is that if I disconnect Xpra client and reconnect, I will find the ssh connection is established.

For the dbus,

By -v /run/dbus/system_bus_socket:/run/dbus/system_bus_socket and --privileged for the xpra docker.
Now xpra can connect to the host dbus, so we xpra start :23 -d clipboard,ssh --start=xterm

And here is the new log, for the ssh, I will execute ssh -Y HOST command and then disconnect xpra client and reconnect.
Here is the new xpra server log. And the error is similar.
https://pastebin.com/a8NFJBz9

[Simba98]

I added a test on CentOS7 docker to run xpra server.
The error is similar, so the issue strongly points to something missing in the docker.

[Simba98]

Here is the package I tried to installed in CentOS: yum install wget xauth xterm openssh-clients xorg-x11-* -y
And also I tried yum groupinstall "Development Tools"

[totaam]

Please don't use pastebin - it expires and we're left with useless dead links.

[Simba98]

No problem, I will set them no expire and stop using pastebin.

[Simba98]

I have new clues.

I use one Fedora 38 VM and one Fedora 38 docker, install xpra and both run via xpra start :23 --start=xterm -d all --pulseaudio=no
Then run same ssh HOST -Y to the target system in the xterm.
So, I have two very long logs.
By comparing them, I find the Xpra in VM will have log of do_owner_changed() and following is requesting local XConvertSelection from ['Qt Selection Owner for libManager', 'xid=1200004', 'pid=23940'] as 'TARGETS' into 'CLIPBOARD-TARGETS'
Then,

owner_change(<Gtk.Clipboard object at 0x7f07c9edc100 (GtkClipboard at 0x55ababfd88d0)>, <Gdk.EventOwnerChange object at 0x7f07c01219f0 (void at 0x55abac96e6c0)>) selection=CLIPBOARD

But the Xpra in Docker doesn't have them.

The logs are 7MB each, very large, and may have my personal information; so, they are not suitable for publishing here.
I can email you them if you would like to have them.

[Simba98]

After upgrade cuda and nvidia driver from 12.1 to 12.2, this issue disappeared.
I think it is related to cuda or nvidia or something that nvidia would change it during install cuda.
What I did is the following.

1. I did apt upgrade, apt dist-upgrade, and apt full-upgrade. And then run xpra to test, we still can find this issue.
2. Due to apt full-upgrade can not upgrade Nvidia cuda and its driver (do not know why), run apt install cuda and apt autoremove.
3. Then this issue disappeared.

[totaam]

That doesn't make sense:

• your issue was with Fedora in a container, how could running apt fix anything?
• for CUDA to somehow change how the clipboard behaves is extremely smelly - sounds like some kind of locking / memory corruption, or at best a race condition

[Simba98]

This does not make sense, I agree.

your issue was with Fedora in a container, how could running apt fix anything?

One of my blinding is all fedora docker is run on an Ubuntu host machine, and run apt on the Ubuntu host fixes the issue.

for CUDA to somehow change how the clipboard behaves is extremely smelly - sounds like some kind of locking / memory corruption, or at best a race condition

I can't give you more information here, maybe I can create an Ubuntu VM with an assigned NV GPU and install Cuda 12.1 to see if I can reproduce it.
However, Nvidia does not provide the specified version (nv always takes down old versions). I doubt if I can reproduce it.

A further test shows that a clean, new, without GPU, Ubuntu VM, I cannot reproduce the issue.
Maybe my config was wrong and apt install cuda accidentally fix it??? But how does the host OS setting influence xpra in docker?
Before the issue disappeared, I tried docker from Ubuntu and docker from the official repo. And I did apt prune docker.io and apt prune docker-ce. And rebooted many times.

It is very hard to survey the reason, thank you for reading.