xpra start ssh: issues with --damon=no, --use-display, --xvfb

[mviereck]

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:
  /run/user/1000/xpra/:25.log

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!

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

[Antoine Martin]

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:

• one fixed in r16135
• another pending

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)

[Antoine Martin]

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

[Antoine Martin]

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

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