Not sure when it was introduced but on 0.15.6 I've just noticed that xpra stop :33 kills both xpra's :33 and the host Xorg :0 taking down my Cinnamon DE and all opened applications. 100% reproducible but only when Xpra's Xorg is started.
Sounds like something in your DE is getting messed up, very unlikely to be caused by xpra. Killing the Xvfb process should not be doing this.
You can confirm by using xpra exit to cause xpra to exit without killing the vfb, then kill it by hand.
Thanks for troubleshooting advise. That's right, xpra exit stops Xpra without killing Xorg but sending SIGTERM to Xpra's child Xorg affect Desktop Environment. Apparently particular DE does not matter, I tried XFCE4 and the effect is the same. This is on Debian "testing" with "xserver-xorg-core" v1.17.3-2... Could be a problem in Xorg...
Could be anything: Xorg, dbus, etc.. (sounds like a serious bug too)
Closing as invalid because I am pretty confident that you could reproduce the same behaviour without using xpra at all: just starting the same apps on a plain vfb.
If you do find the answer / culprit, please share it.
Just a thought: try ssh localhost then start the session from there.
This will run from a brand new login shell, and will reduce the environment variables that are shared with the "real" X11 session.
If it is because of an environment variable, we could blacklist it and filter it out.
Wow, Xorg started by xpra start :33 in "ssh localhost" session do not kill Xorg :0 on stop.
I'm not sure how to track responsible ENV variable. Some suspicious ones that are not set in SSH session are DBUS_SESSION_BUS_ADDRESS, DESKTOP_AUTOSTART_ID, DISPLAY, SESSION_MANAGER, XDG_CURRENT_DESKTOP, XDG_SESSION_ID, XDG_VTNR, XDG_SEAT, XDM_MANAGED...
The obvious ones to disable first: DBUS_SESSION_BUS_ADDRESS and maybe XDG_SEAT / XDG_VTNR. We override DISPLAY so that should be safe.
I tried to unset all of those variables but it did not help... :( Not sure what else to do and have no time for further experiments... :(
Maybe you start things in /etc/xpra/xpra.conf? from Xsession perhaps?
See also #1104.
Any new discoveries about this problem?
I start nothing from xpra.conf or from Xsession and I tried to unset almost all environment variables before xpra start but that did not help...
Until this can be reproduced reliably on a test system with our builds, I don't think anyone is going to spend too much time on this. (I am not installing debian on my systems, and the problem does not occur with a VM)
Interesting to note that Xorg remains running but active display with desktop environment is terminated (sometimes leaving garbage on screen).
Maybe xpra start in xterm from under active desktop environment (e.g. Cinnamon) may help to reproduce the issue...
Similar to firejail: Program in X11 sandbox can kill host X session and #2332
I'm able to reproduce this on xpra v3.0.4-r24778 with Ubuntu 19.04 as the host OS, using i3wm as the window manager. Would any debugging information be helpful from me to try to track this down (or at least point those experiencing this in the right direction).
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1032