xpra icon
Bug tracker and wiki

Opened 4 months ago

Closed 2 months ago

#2834 closed defect (fixed)

Xpra stop crashes X Display :0

Reported by: brady Owned by: brady
Priority: major Milestone: 4.1
Component: server Version: 4.0.x
Keywords: Cc:

Description

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-r26625
OS: Ubuntu 18.04 amd64
Desktop Environment: KDE Plasma 5

Attachments (2)

after-stop.png (3.2 KB) - added by grady 3 months ago.
image of the boot log after kde has crashed
55_server_x11.conf (1.6 KB) - added by grady 3 months ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 4 months ago by Antoine Martin

Owner: changed from Antoine Martin to brady

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.

comment:2 Changed 3 months ago by Antoine Martin

Resolution: invalid
Status: newclosed

Not heard back.

comment:3 Changed 3 months ago by grady

Resolution: invalid
Status: closedreopened

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?

Changed 3 months ago by grady

Attachment: after-stop.png added

image of the boot log after kde has crashed

comment:4 Changed 3 months ago by Antoine Martin

Status: reopenednew

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)

Changed 3 months ago by grady

Attachment: 55_server_x11.conf added

comment:5 in reply to:  4 Changed 3 months ago by grady

Replying to 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.

comment:6 Changed 3 months ago by Antoine Martin

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.

comment:7 Changed 3 months ago by grady

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.

comment:8 Changed 3 months ago by grady

Replying to 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.

comment:9 Changed 3 months ago by Antoine Martin

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.

comment:10 Changed 2 months ago by grady

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

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

comment:11 Changed 2 months ago by Antoine Martin

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?

comment:12 Changed 2 months ago by grady

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. 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.

comment:13 Changed 2 months ago by Antoine Martin

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.