#1558 closed defect (worksforme)
xpra start ssh: issues with --damon=no, --use-display, --xvfb
Reported by: | mviereck | Owned by: | mviereck |
---|---|---|---|
Priority: | minor | Milestone: | 2.1 |
Component: | server | Version: | 2.0.x |
Keywords: | ssh --xvfb --use-display --damon | Cc: |
Description
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!
Change History (5)
comment:1 Changed 5 years ago by
comment:2 Changed 5 years ago by
Milestone: | → 2.1 |
---|---|
Status: | new → assigned |
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)
comment:3 Changed 5 years ago by
Owner: | changed from Antoine Martin to mviereck |
---|---|
Status: | assigned → new |
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 ...
comment:4 Changed 5 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
This got tested pretty well on Debian these last few days.
Feel free to re-open if I've missed something.
comment:5 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1558
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.