Xpra stop crashes X Display :0

[totaam]

Issue migrated from trac ticket # 2834

component: server | priority: major | resolution: fixed

2020-07-08 17:59:00: brady created the issue

---

If I start an xpra session using xpra start :100, and then run the command xpra stop, xpra will not only stop the xpra session, but will also kill my original x session running on DISPLAY :0. It did not kill the applications that were running on that X Server either.

This rather annoyingly caused a situation in which a program running on X Display :0 was able to capture my keystrokes that I entered into a tty to try to recover my session.

Xpra version: xpra v4.0.2-26625
OS: Ubuntu 18.04 amd64
Desktop Environment: KDE Plasma 5

[totaam]

but will also kill my original x session running on DISPLAY :0.
It did not kill the applications that were running on that X Server either.

That's not possible.
X11 applications will be forcibly terminated when the X11 server shuts down.

This rather annoyingly caused a situation in which a program running on X Display :0 was able to capture my keystrokes that I entered into a tty to try to recover my session.

Then your X11 server was not killed. Maybe just a VT switch instead?
And a buggy one at that, the X11 server should not be getting console events when you switch VTs.

The Xpra server does not, and should not be able to, interact with other X11 servers.
This is likely a bug in Ubuntu's packaging or configuration, or the KDE packages.
This does not occur with other distros: not with Fedora which I use daily, or with Ubuntu 18.04 running in a virtual machine..

You may want to try to switch to Xvfb instead of Xdummy and see if that resolves your issue, you can do that by editing /etc/xpra/conf.d/55_server_x11.conf.

[totaam]

2020-08-14 23:30:51: grady commented

---

I have this same exact problem.

OS: Kubuntu 20.04 (focal) minimal install
virtual machine
Desktop Environment: KDE plasma 5

I think the conditions can be reliably reproduced from a fresh Kubuntu minimal install on a virtual machine with xpra installed from repositories

xpra start #wait for the server to finish initialization
xpra stop

This seemingly kills the KDE plasma session. I see the boot log as if the desktop environment has exited.

I can end the plasma_session process from a virtual terminal to recover KDE. Switching between virtual terminals does not fix the problem.

In a virtual machine, KDE spontaneously recovers if I resize the window on the host machine or change the size of the virtual display. This may be an artifact of the virtualization display driver. Can someone confirm if this behavior is present on non-virtualized systems?

[totaam]

2020-08-14 23:31:30: grady uploaded file after-stop.png (3.2 KiB)

image of the boot log after kde has crashed

[totaam]

In a virtual machine, KDE spontaneously recovers if I resize the window on the host machine or change the size of the virtual display

This looks like something related to VT switching, but we do run Xorg with -novtswitch. (see xpra showconfig | grep xvfb)
So I am still very confident that this is an Ubuntu bug and not a bug in xpra.
Though we may be able to mitigate it by using Xvfb.

Have you tried using Xvfb instead of Xdummy? (as per comment:1)

This could also be related to dbus or another KDE component, that somehow leaks from one session to another. (you could try starting the xpra session as a different user to see if the problem goes away then)

[totaam]

2020-08-15 06:58:20: grady uploaded file 55_server_x11.conf (1.6 KiB)

[totaam]

2020-08-15 07:50:46: grady commented

---

Replying to [comment:4 Antoine Martin]:

In a virtual machine, KDE spontaneously recovers if I resize the window on the host machine or change the size of the virtual display

This looks like something related to VT switching, but we do run Xorg with -novtswitch. (see xpra showconfig | grep xvfb)

Here's my xpra showconfig | grep xvfb
xvfb = '/usr/lib/xorg/Xorg -noreset -novtswitch -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth $XAUTHORITY -logfile ${XPRA_LOG_DIR}/Xorg.${DISPLAY}.log -configdir ${XDG_RUNTIME_DIR}/xpra/xorg.conf.d/$PID -config /etc/xpra/xorg.conf'

So I am still very confident that this is an Ubuntu bug and not a bug in xpra.

I guess it could be related to how some flavors of Ubuntu have the X11 session on tty1. The official distribution of Ubuntu has the X11 on tty7.

Though we may be able to mitigate it by using Xvfb.
Have you tried using Xvfb instead of Xdummy? (as per comment:1)

I have attached my 55_server_x11.conf​. I don't understand how I can switch from Xdummy to Xvfb. I don't see any reference to Xdummy in the config file and the last line has Xvfb = ...

This could also be related to dbus or another KDE component, that somehow leaks from one session to another. (you could try starting the xpra session as a different user to see if the problem goes away then)

Great idea! The KDE session didn't crash for the first user when I started and stopped xpra from a different user account.

[totaam]

I don't understand how I can switch from Xdummy to Xvfb

Comment out the line at the end of the file, uncomment the one that has xvfb = Xvfb ...

The KDE session didn't crash for the first user when I started and stopped xpra from a different user account.

So it's likely related to dbus or something like that.
You may want to try to start your sessions from a "cleaner" shell environment than the one that is running in your KDE desktop session, as something may be leaking into the xpra session context.

One way to do this would be to login via ssh to localhost, and run xpra from there.
Or just: xpra start ssh://localhost/ --start=xterm.

[totaam]

2020-08-15 08:34:55: grady commented

---

something may be leaking into the xpra session context.

The problem does seem to be related to starting xpra within the current KDE session. With a su to a different user, xpra stop does not blank the KDE session. With a su to the same user, the bug is present.

One way to do this would be to login via ssh to localhost, and run xpra from there.
Or just: xpra start ssh://localhost/ --start=xterm

I can confirm that starting xpra over ssh to the same user account mitigates this problem, even when the ssh is from within the KDE session.

[totaam]

2020-08-15 08:44:31: grady commented

---

Replying to [comment:6 Antoine Martin]:

I don't understand how I can switch from Xdummy to Xvfb
I switched to the Old Xvfb option (required on Ubuntu where Xorg is broken) but xpra failed to start due to an error

xpra initialization error:
 Xvfb: did not provide a display number using displayfd

My /usr/bin/Xorg -version. This should be the latest version for Kubuntu 20.04 (focal).

X.Org X Server 1.20.8
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.4.0-184-generic x86_64 Ubuntu
Current Operating System: Linux Kubuntu 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-42-generic root=/dev/mapper/vgkubuntu-root ro quiet splash
Build Date: 24 June 2020  06:00:21AM
xorg-server 2:1.20.8-2ubuntu2.2 (For technical support please see http://www.ubuntu.com/support) 
Current version of pixman: 0.38.4
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.

[totaam]

I switched to the Old Xvfb option ...

Is the Xvfb command installed?

With a su to the same user, the bug is present.

Can you try su --login?

I can confirm that starting xpra over ssh to the same user account mitigates this problem

Can you diff the two environments?
ie:

env > env-kde

env > env-ssh

Then

diff -u env-kde env-ssh

Or delete environment variables until you locate the one that is causing problems.

Maybe we should safe-list the environment variables that we allow through, but for now we use blocklist.

[totaam]

2020-08-15 09:24:29: grady commented

---

su --login with xvfb = /usr/lib/xorg/Xorg ... (With Xorg 1.12 or newer and the dummy driver:)
still has the bug.

Is the Xvfb command installed?

Oops. Thanks.
sudo apt install xvfb

You may want to try to switch to Xvfb instead of Xdummy [comment:1 comment:1]

I can confirm the Xvfb method does not crash the KDE session when xpra is closed.

[totaam]

Is the Xvfb command installed?

Oops. Thanks.
sudo apt install xvfb

That's very odd. The xvfb package is a hard dependency of the xpra package.
It must be installed for you to have xpra installed.
Did you install from source or something? (or not using a package from xpra.org?)

I can confirm the Xvfb method does not crash the KDE session when xpra is closed.

Right, so Debian or Ubuntu must be configuring / patching something in the X11 server which is causing these problems.

This is potentially a security issue too as this gives the ability to kill a session and a whole bunch of processes that we have no business touching..

But whatever, they're very unlikely to ever fix this.
So, r27165 switches to Xvfb instead of Xdummy, only on Debian and Ubuntu. (I will backport this change to v3.0.x and v4.0.x).

When users complain of DPI issues on Debian or Ubuntu, I can just point them here and tell them to switch back to Xdummy if they understand the risks.

Can we close this ticket?

[totaam]

2020-08-18 02:51:20: grady commented

---

Or delete environment variables until you locate the one that is causing problems.

Tested deleting all differing environment variables, did not resolve the crash.

Did you install from source or something? (or not using a package from xpra.org?)

I installed from the xpra.org deb package. My install may be missing several dependencies (such as in #2862 missing python3-gi-cairo) so I think this would be more appropriate for a separate ticket.

So, r27165 switches to Xvfb instead of Xdummy, only on Debian and Ubuntu. (I will backport this change to v3.0.x and v4.0.x).
When users complain of DPI issues on Debian or Ubuntu, I can just point them here and tell them to switch back to Xdummy if they understand the risks.

I have only confirmed this bug on Kubuntu, which does not necessarily represent all of Debian or Ubuntu. For our purposes, this one of the many official Ubuntu flavours has a particularly unusual configuration compared to the others. The impact could be limited to KDE, or virtual machines, or KDE on virtual machines. I haven't tested if this bug affects older versions of Ubuntu.

This is potentially a security issue too as this gives the ability to kill a session and a whole bunch of processes that we have no business touching..

The session doesn't actually die; it remains live, but inaccessible. After I resize the virtual display, the session reappears in its previous state [comment:3 comment:3]. So it is possible to recover the system without ending the session. However, resizing the display may not be practical on physical machines without access to the X11 session. I suspect that the system can be non-destructively recovered through a virtual terminal.

[totaam]

With a su to a different user, xpra stop does not blank the KDE session
Tested deleting all differing environment variables, did not resolve the crash.

Odd. There really isn't much difference between the two.

My install may be missing several dependencies

It should be impossible to install xpra without also installing xvfb unless you force the package install with dpkg. Feel free to create a separate ticket.

The impact could be limited to KDE, or virtual machines, or KDE on virtual machines

It's been reported enough times that it is safer to use xvfb by default from now on.

So it is possible to recover the system without ending the session

Unfortunately, most users won't know that xpra is not to blame, or that there is a way to recover the session.

Closing as fixed as from now on the official xpra packages will be using xvfb.

[basilgello]

@totaam

Let's hope new Debian versions…

No room for false hopes. I had to revert this commit to make Xorg not deallocate a tty.

[totaam]

Reverted in 873060b.

Seeing that a huge number of bugs are being resolved by switching to xrandr Xdummy (#56), the only recommendation I can make is to avoid Debian with xpra.

[totaam]

Checked again and in 2024, the Debian version of Xorg is still butchered and unusable as non-root!
https://github.com/Xpra-org/xpra/wiki/Distribution-Packages#specific-distributions