Xpra: Ticket #1558: xpra start ssh: issues with --damon=no, --use-display, --xvfb

system: debian stretch with xpra v2.0.2-r15657

I am trying some possibilities with xpra start ssh:server:display and encounter some issues. Sample command:

xpra start ssh:localhost:25 --xvfb="/usr/bin/Xephyr :25" --daemon=no

1.) option --daemon=no shows me

Entering daemon mode; any further errors will be reported to:

I have some entrys in the logfile and some output in terminal. I've expected to get all output in terminal.

2.) The --xvfb switch with a custom X command seems to be ignored. pgrep -xa Xorg shows me for the example above:

15640 /usr/lib/xorg/Xorg-for-Xpra-:30 -noreset -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth /home/lauscher/.Xauthority -logfile /run/user/1000/xpra/Xorg.:30.log -configdir /home/lauscher/.xpra/xorg.conf.d -config /etc/xpra/xorg.conf -depth 24 :30

3.) option --use-display to attach an X server I've started before causes some errors because xpra tries to start its own X server with same display number. Surprisingly, attaching with xpra attach ssh:... works even if xpra server terminates. It seems that ssh is initialized successfully and xpra attach ssh:... works even with a crashed xpra server.

As these are my first trials with ssh, I may have misunderstood something. I hope you can shed some light. Thanks!

Tue, 27 Jun 2017 22:34:37 GMT - mviereck:

Sorry, one minor mistake above: I've cited :25 and :30 from different tests, but it is meant to be the same display. Just exchange :25 with :30. I've used xpra attach ssh:localhost:30 to attach.

Wed, 28 Jun 2017 10:08:11 GMT - Antoine Martin: status changed; milestone set

The code has been re-worked completely to be able to implement logind support (#1105) and now supports forwarding pretty much all attributes via ssh start. (and also via remote ssl / tcp start since it now shares the same code)

Unfortunately, I've just found two bugs:

Will re-assign to you when that's complete.

Note: the daemon flag is a special case and should not be honoured because this would cause the whole session to be killed should the connection be lost. (and also because of the code that handles starting new servers - though this could be changed)

Wed, 12 Jul 2017 12:29:25 GMT - Antoine Martin: owner, status changed

The issues from comment:2 are now fixed. There may still be packaging issues on Debian to do with the systemd bits (#1105), but if the system wide proxy server is not running then the "xpra start" command should default back to the old way of starting the server. If somehow it fails more catastrophically, you can try to start with:

xpra start --start-via-proxy=no ...

Tue, 25 Jul 2017 16:59:01 GMT - Antoine Martin: status changed; resolution set

This got tested pretty well on Debian these last few days.

Feel free to re-open if I've missed something.

Sat, 23 Jan 2021 05:27:37 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1558