xpra icon
Bug tracker and wiki

Opened 5 weeks ago

Closed 4 weeks ago

Last modified 4 weeks ago

#1451 closed defect (invalid)

black screen after exit of xpra server on debian 9

Reported by: mviereck Owned by: mviereck
Priority: critical Milestone: 2.0
Component: server Version: 0.17.x
Keywords: vt black screen Cc:

Description

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!

Change History (11)

comment:1 Changed 5 weeks ago by mviereck

Cc: bachbaum24@… added

comment:2 Changed 5 weeks ago by Antoine Martin

Cc: bachbaum24@… removed
Owner: changed from Antoine Martin to mviereck

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.

comment:3 Changed 5 weeks ago by 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.

comment:4 Changed 5 weeks ago by 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.

comment:5 Changed 5 weeks ago by 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

comment:6 Changed 4 weeks ago by 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.

comment:7 Changed 4 weeks ago by 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.

comment:8 Changed 4 weeks ago by 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

Last edited 4 weeks ago by mviereck (previous) (diff)

comment:9 Changed 4 weeks ago by Antoine Martin

Milestone: 2.0
Resolution: invalid
Status: newclosed

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.

comment:10 Changed 4 weeks ago by 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? :(

comment:11 Changed 4 weeks ago by 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.

Note: See TracTickets for help on using tickets.