xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 5 years ago

Last modified 8 months ago

#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 (16)

comment:1 Changed 5 years ago by onlyjob

Component: androidcore

comment:2 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to onlyjob

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.

comment:3 Changed 5 years ago by onlyjob

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 Antoine Martin

Resolution: invalid
Status: newclosed

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 Antoine Martin

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.

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:6 Changed 5 years ago by onlyjob

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 Antoine Martin

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 onlyjob

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 Antoine Martin

Maybe you start things in /etc/xpra/xpra.conf? from Xsession perhaps?

comment:10 Changed 5 years ago by Antoine Martin

See also #1104.

comment:11 Changed 4 years ago by onlyjob

Version: 0.15.x0.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 4 years ago by Antoine Martin

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 4 years ago by onlyjob

Interesting to note that Xorg remains running but active display with desktop environment is terminated (sometimes leaving garbage on screen).

comment:14 Changed 4 years ago by onlyjob

Maybe xpra start in xterm from under active desktop environment (e.g. Cinnamon) may help to reproduce the issue...

comment:15 Changed 11 months ago by Antoine Martin

Last edited 11 months ago by Antoine Martin (previous) (diff)

comment:16 Changed 8 months ago by Phil S

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).

Note: See TracTickets for help on using tickets.