Somewhat hard to reproduce, but finally got a trace. I managed to get the server in a spin where it would not respond to its socket (UI main loop trouble), then when I tried to upgrade the session:
Traceback (most recent call last): File "/usr/bin/xpra", line 6, in <module> sys.exit(xpra.scripts.main.main(__file__, sys.argv)) File "xpra/scripts/main.py", line 406, in main return run_server(parser, options, mode, script_file, args) File "xpra/scripts/server.py", line 496, in run_server app = XpraServer(clobber, sockets, opts) File "xpra/server.py", line 163, in __init__ X11ServerBase.__init__(self, clobber, sockets, opts) File "xpra/x11_server_base.py", line 62, in __init__ self.x11_init(clobber) File "xpra/server.py", line 182, in x11_init self._wm = Wm("Xpra", clobber) File "wimpiggy/wm.py", line 245, in __init__ for w in get_children(self._root): File "bindings.pyx", line 650, in wimpiggy.lowlevel.bindings.get_children (wimpiggy/lowlevel/bindings.c:7007) File "bindings.pyx", line 637, in wimpiggy.lowlevel.bindings._query_tree (wimpiggy/lowlevel/bindings.c:6832) File "bindings.pyx", line 413, in wimpiggy.lowlevel.bindings.get_pywindow (wimpiggy/lowlevel/bindings.c:3304) wimpiggy.error.XError: XError: 3 2013-04-16 01:04:46,521 closing tcp socket 0.0.0.0:10000 2013-04-16 01:04:46,522 removing socket /home/antoine/.xpra/desktop-10 2013-04-16 01:04:46,523 killing xvfb with pid 30147
BadWindow here is unexpected, and maybe we ought to deal with that better.
But in any case, we should not kill the xvfb if we failed to initialize properly.
avoid killing Xvfb unless we are ready to service the main loop done in r3080
As for the stacktrace above, not too sure what to do with it - would be better if I could reproduce it at will (I've seen it more than once..).
This will do for now.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/311