xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 8 years ago

Closed 7 years ago

Last modified 12 months ago

#612 closed enhancement (fixed)

automatic DISPLAY selection over ssh

Reported by: Antoine Martin Owned by: alas
Priority: minor Milestone: 0.16
Component: server Version:
Keywords: Cc:


Split from #172.

Remote start via ssh no longer needs a display to be specified. The difficulty is twofold:

  • we don't know in advance if the other end supports displayfd, and if it doesn't we need to detect that this is what happened and tell the user
  • the connection string we generate for the client uses the display... and we don't have it yet. There is currently no way of knowing what display was chosen either!

Change History (9)

comment:1 Changed 7 years ago by Antoine Martin

Milestone: future0.16
Status: newassigned

Now that we don't support older distros, we can assume displayfd is available.
(except maybe for some older Ubuntu versions? Meh, don't care about those)

comment:2 Changed 7 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

done in r9683 + r9684.

@afarr: this is just a FYI, but feel free to test or just close this ticket.

This should now work as long as the server has xpra installed:

xpra start --start-child=xterm ssh:hostname

Previous versions required the form:

xpra start --start-child=xterm ssh:hostname:DISPLAY

Which required choosing a display number in advance, without knowing if it would actually be free.

comment:3 Changed 7 years ago by J. Max Mena

Attempted to start a r9688 Trunk Fedora 21 Server:

  • Got the following traceback when starting with xpra start --start-child=xterm ssh:localhost :
[max@schlafanzug ~]$ xpra start --start-child=xterm ssh:localhost
/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning: could not open display
  warnings.warn(str(e), _gtk.Warning)
/usr/lib64/python2.7/site-packages/xpra/client/gtk2/__init__.py:7: GtkWarning: IA__gdk_screen_get_root_window: assertion 'GDK_IS_SCREEN (screen)' failed
  from xpra.x11.gtk_x11 import gdk_display_source
/usr/lib64/python2.7/site-packages/xpra/gtk_common/gtk_util.py:181: GtkWarning: IA__gdk_cursor_new_for_display: assertion 'GDK_IS_DISPLAY (display)' failed
  default_Cursor          = gdk.Cursor(gdk.X_CURSOR)
xpra main error:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 114, in main
    return run_mode(script_file, err, options, args, mode, defaults)
  File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 898, in run_mode
    return run_remote_server(error_cb, options, args, mode, defaults)
  File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 1357, in run_remote_server
    app = make_client(error_cb, opts)
  File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 1294, in make_client
    toolkit_module = __import__(client_module, globals(), locals(), ['XpraClient'])
  File "/usr/lib64/python2.7/site-packages/xpra/client/gtk2/client.py", line 24, in <module>
    from xpra.gtk_common.gtk_util import gtk_main, color_parse
  File "/usr/lib64/python2.7/site-packages/xpra/gtk_common/gtk_util.py", line 181, in <module>
    default_Cursor          = gdk.Cursor(gdk.X_CURSOR)
RuntimeError: could not create GdkCursor object

In addition, the server crashes.

For what it's worth: Also specifying a display number also outputs the same traceback. Not sure if it's legitimately broken or I have no idea how to start an ssh session. TCP is working, however (which is how I'm typing this comment..)

comment:4 Changed 7 years ago by Antoine Martin

This means that you are attempting to start a session from a terminal which cannot access your display - this won't work, whether you specify the remote display or not: (and has little to do with this ticket!)

/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning: could not open display

You need to run this command from a client, without starting a server in advance - it will be started for you.

comment:5 Changed 7 years ago by Antoine Martin

Here's another way of triggering those same errors using an invalid display with the X11 client:

DISPLAY="" xpra attach

comment:6 Changed 7 years ago by J. Max Mena

Now that I've confirmed I'm a moron:

  • Started from my Fedora 20 box (same version) against Fedora 21 (same version) with

xpra start --start-child=xterm ssh:uname@testvm

Everything works as expected.

comment:7 Changed 7 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

@maxmylyn: LOL - thanks for testing!

FWIW: I do have plans to refactor the gtk initialization code as part of #640, which would allow us to bail out earlier when the DISPLAY is not set, giving a more friendly error message for those cases.

comment:8 Changed 7 years ago by Antoine Martin

@maxmylyn: FYI, as of r9721, the error message has been improved:

  • gtk2:
    $ DISPLAY= python2 /usr/bin/xpra attach  --no-speaker
    /usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning: could not open display
      warnings.warn(str(e), _gtk.Warning)
    xpra initialization error: cannot access the display
  • gtk3:
    $ DISPLAY= python3 /usr/bin/xpra attach --no-speaker
    Unable to init server: Could not connect: Connection refused
    xpra initialization error: cannot access the display

I could also intercept the gtk2 warnings, but I think this is clear enough as it is.

comment:9 Changed 12 months ago by migration script

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

Note: See TracTickets for help on using tickets.