Xpra: Ticket #1451: black screen after exit of xpra server on debian 9

setup: xpra server and client on same machine. Version v0.17.06 OS: debian 9 testing command to start server:

xpra start :20 --start-child=xterm --exit-with-children

command to start client:

xpra attach :20

Closing xterm window shown by xpra leads to black screen on host, desktop is ot accessable anymore.

Related debian bugreport: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855980 Same issue with --xvfb option using Xdummy.

Solution: With --xvfb option and Xdummy, add X option vtN (for example, vt20 for display :20) to specify a virtual terminal to use. This should be done by xpra itself if not using --xvfb.

Thanks for xpra, it's great!

Fri, 24 Feb 2017 04:36:26 GMT - mviereck: cc set

Fri, 24 Feb 2017 04:41:33 GMT - Antoine Martin: owner changed; cc deleted

No other distribution is seeing those problems. What is Debian testing doing different here?

This doesn't look like an xpra bug: you should be able to get the same results by simply starting the Xvfb and stopping it. (no need to start an xpra session at all) Each Xvfb session should be independent and should not be able to affect the others. I'm not convinced it is wise to choose VT numbers at (semi)random either, especially when we have never needed to do so.

Finally, the 0.17.x branch has been EOL for 3 months and is no longer maintained. Complain to your distributor for shipping unmaintained software.

Fri, 24 Feb 2017 05:09:03 GMT - mviereck:

No other distribution is seeing those problems. What is Debian testing doing different here?

debian 9 introduces permission control for X servers by systemd to avoid using setuid wrappers for Xorg. This seems to affect Xvfb, too.

This doesn't look like an xpra bug: you should be able to get the same results by simply starting the Xvfb and stopping it.

Yes, it is not an xpra bug at first and I can reproduce it with Xvfb and Xdummy on their own. but I cannot set vt in xpra itself except using --xvfb.

No other distribution is seeing those problems.

If this won't change in debian, it will affect all distributions that will base on it.

Fri, 24 Feb 2017 05:17:36 GMT - Antoine Martin:

Do you have any links for this new systemd feature?

Xorg has been working just fine without setuid wrappers for many years, this breaks it and looks like a clear regression: one vfb instance should not be able to affect another. Adding an extra VT argument to every tool that runs Xorg is tackling the problem from the wrong end.

Fri, 24 Feb 2017 10:06:34 GMT - mviereck:

I only find a few hints pointing on this. I refer to this debian bugreport: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801401

I've posted a related question on stackexchange: http://unix.stackexchange.com/questions/346383/run-second-x-server-from-within-x-as-a-systemd-service

Mon, 27 Feb 2017 13:11:58 GMT - Antoine Martin:

One more thing: for over 3 years we have not needed to specify the display to use, ie:

xpra start --start=xterm

If we need to allocate a VT on some platforms, how on earth can we choose which VT to use in advance seeing that Xorg will allocate the DISPLAY number itself. Again, the logic to do this should not have to be added to all applications. It is the wrong place.

Wed, 01 Mar 2017 12:20:17 GMT - mviereck:

I agree to your point of view. I hope there will be some response to my bug ticket on debian's bugtracker for xinit I've linked above. Maybe I should have marked it as "critical" instead of normal as the bug destroys X sessions completly.

Wed, 01 Mar 2017 14:36:10 GMT - mviereck:

I have checked xpra v1.0.3 with debian 9 in a VM. The bug described above does not appear. I have reported a bug to debian for xpra and recommended to include v1.0.3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856485

Thu, 02 Mar 2017 15:27:31 GMT - Antoine Martin: status changed; resolution, milestone set

Since this is not a problem with the supported version, I am closing this as "invalid".

Debian should not be shipping an unsupported version... 1.0.x was released long before the freeze. Not for the first time that the package is fundamentally broken in Debian either, see wiki/Packaging/DistributionPackages for details.

Thu, 02 Mar 2017 20:19:24 GMT - onlyjob:

As I recall Xpra 1.0 was released during freeze. Besides 1.0 introduced new dependencies so it will need more time to prepare and to test.

Antoine, would you prefer Debian not to ship Xpra at all or shall we drop it from just from stable release? I shall be happy to arrange that as I'm upset reading rude, unfair and inaccurate things you say about Debian again. :(

Also you are blaming previous release of your own product for being "fundamentally broken". That's not true like if it was working perfectly up until 1.0 at which point 0.17.6 suddenly became "fundamentally broken"? Seriously? :(

Fri, 03 Mar 2017 01:14:11 GMT - Antoine Martin:

The packaging in Debian is provably broken (see lots of details in the link above): Debian ships versions with hundreds of known bugs, including critical CVEs. If that fact is unpalatable, do something about it and fix it. Otherwise, "get off my lawn" (tracker).

Further comments will be deleted.

Wed, 29 Mar 2017 17:50:13 GMT - mviereck:

Just FYI:

I faced this bug again with xpra v2.0-r15319. At least I could track down that it is related to the display manager in use. So far I've tested, the issue occurs with lightdm, sddm and lxdm. It does not yet occur with gdm3 or if starting X from console without any dm.

A similar (or same?) bug randomly occurs (independent from xpra) if I switch between multiple X displays and ttys - and it always only affects the X session started by the display manager.

Tue, 02 Jul 2019 07:57:04 GMT - mviereck:

Just a note: x11docker defaults to use Xvfb for xpra if available and falls back to Xdummy if not. I avoid this issue setting vt128 for Xdummy. Valid values for real vt's are 0...63.

Xdummy does not need a vt. But it seems it deallocates it if it terminates. This is probably rather an issue in Xorg than in the dummy driver itself.

I found that it causes no issue to run multiple Xdummy with vt128. I've decided to avoid the range of 0..63 because I cannot verify for sure that a single vt is not in use. fgconsole does not work in X, and /sys/class/vc does not show vt numbers (un)used by Xdummy so others might use it and interfere with Xdummy.

vt128 is not a clean solution because it uses a number out of range. However, it causes no issues and avoids crashes.

Fri, 18 Sep 2020 15:34:21 GMT - Antoine Martin:

FYI: we've had just too many problems with Debian causing crashes like these (see xpra: terminating xpra server destroys current X session) - whatever they're doing to the Xorg installation, it's causing these huge problems.

This is having a very negative impact on the image of xpra as users just cannot guess that the problem is caused by Debian and not xpra. Display server crashes are as bad as it gets, and since they're clearly not going to fix this mess, the next xpra release will switch to Xvfb for all Debian and Ubuntu packages.

Sat, 23 Jan 2021 05:24:39 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1451