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!
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.
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.
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.
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
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.
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.
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
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.
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? :(
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 CVE
s. If that fact is unpalatable, do something about it and fix it.
Otherwise, "get off my lawn" (tracker).
Further comments will be deleted.
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.
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.
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.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1451