#1032 closed defect (invalid)
"stop" command kills host X
Reported by: | onlyjob | Owned by: | onlyjob |
---|---|---|---|
Priority: | critical | Milestone: | 0.16 |
Component: | core | Version: | 0.16.x |
Keywords: | Cc: |
Description
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.
Change History (17)
comment:1 Changed 5 years ago by
Component: | android → core |
---|
comment:2 Changed 5 years ago by
Owner: | changed from Antoine Martin to onlyjob |
---|
comment:3 Changed 5 years ago by
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...
comment:4 Changed 5 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
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.
comment:5 Changed 5 years ago by
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.
comment:6 Changed 5 years ago by
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
...
comment:7 Changed 5 years ago by
The obvious ones to disable first: DBUS_SESSION_BUS_ADDRESS
and maybe XDG_SEAT
/ XDG_VTNR
. We override DISPLAY
so that should be safe.
comment:8 Changed 5 years ago by
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... :(
comment:9 Changed 5 years ago by
Maybe you start things in /etc/xpra/xpra.conf
? from Xsession
perhaps?
comment:11 Changed 5 years ago by
Version: | 0.15.x → 0.16.x |
---|
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...
comment:12 Changed 5 years ago by
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)
comment:13 Changed 5 years ago by
Interesting to note that Xorg remains running but active display with desktop environment is terminated (sometimes leaving garbage on screen).
comment:14 Changed 5 years ago by
Maybe xpra start
in xterm
from under active desktop environment (e.g. Cinnamon) may help to reproduce the issue...
comment:15 Changed 18 months ago by
Similar to firejail: Program in X11 sandbox can kill host X session and #2332
comment:16 Changed 14 months ago by
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).
comment:17 Changed 5 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1032
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.