Can I start a GUI application from inside GNU Screen?
You can't. Well... At least, you have to set
DISPLAYbefore invoking it.
When I disconnect and reconnect, will it still be there?
No, of course not!
Right, but... wrong. This post describes how to answer "Yes" to the two questions above.
If you run long tasks or work with multiple shells on a remote Linux/Unix server, GNU
Screen is your friend. It is a virtual
terminal multiplexer that will continue running all your shells and all the
processes started by them even if you disconnect, and of course allow
reconnecting later. Unfortunately, this tool has one drawback: All subprocesses
will inherit the environment at the time Screen was first started, even after
disconnecting and reconnecting. This means that you cannot automatically launch
applications with a GUI in a reconnected Screen session, even if you
enable X forwarding with
ssh -X: The
DISPLAY environment will probably be
wrong. Of course you can note the value of
DISPLAY right after
and start your GUI applications using
DISPLAY=:### my-gui-app -- but that's
very inconvenient. In addition, even if Screen survives a disconnect, the GUI
application won't -- the target display must run at least as long as the
application runs, or the application will terminate. Another option is to
log in separately using
ssh -X for each GUI application and start it outside
Screen -- this is inconvenient if a GUI application needs to be started from a
specific directory (say, a version control front-end or a visual diff tool).
That's where xpra comes to play -- "Screen for X". It
provides and maintains an Xvfb-based
virtual framebuffer on the server to which applications can connect, this
framebuffer is intended to run indefinitely. Xpra clients can then connect to
the xpra server instance and display the contents of the virtual framebuffer on the
local display, forward input events, ... -- in other words, let the user interact
with the application as if it runs on the local machine. Once disconnected,
another connection can be made to the same xpra session -- this is transparent
to GUI applications using xpra as display, these applications simply continue
running. The value of
DISPLAY (and its lifetime) remains unchanged for the entire duration of the
This post describes the installation of xpra and GNU Screen on a Debian/Ubuntu Linux server and client, with the following features:
Login on the server via SSH by default reattaches to a running Screen. If no Screen is running, a new instance is started and xpra is set up in that instance.
Applications with a GUI can be started from within Screen, and keep running even if the client disconnects. Several GUI applications can be run in parallel. They are shown on the client's display by issuing a special command once.
It is assumed that usernames match on both local and remote systems. If this is not the case, some tweaking might be necessary -- YMMV. Some knowledge of Screen is assumed, too.
Tested with xpra 0.9.6 (server, Debian Squeeze) and xpra 0.9.8 (client, Ubuntu 13.04). In principle, the configuration should also work on other Linux flavors.
Server and client
sudo apt-get install xpra.
- Install GNU Screen:
sudo apt-get install screen
Server: Auto-start Screen
The script below needs to be added to or
sourced from your
It is a modified version of
this script. The main changes are:
If no running Screen is found, the
DISPLAYenvironment variable is set to the first free display with number larger than 5555. (This is to avoid confusion with system display numbers.) Free display numbers are discovered by looking into
/tmp/.X11-unix/for files named
DISPLAYenvironment variable will be inherited by the
screeninstance which is started next, and thus also by all processes started inside this Screen. (There is a race condition here: Two simultaneous logins from the same user will set
DISPLAYto identical values, and one instance of xpra will fail to attach to that display.)
DISPLAYenvironment variable is already set, the auto-start feature is disabled. This happens, for instance, if you use
ssh -Xto login to the remote machine.
The window title is set to
Test this by
sshing into your remote machine with and without the
In the latter case, Screen should be started automatically (if no instance was
running previously), in the former case you'll be getting a simple prompt. If
you cannot distinguish the former from the latter, you can customize the
appearance of Screen (e.g., add a permanently
visible status line) by editing your
~/.screenrc file. There are plenty of
examples on the web. (You'll
need to edit that file anyway, see below.) Close the auto-started Screen, this
will also close your SSH connection.
Server: Patch xpra configuration
The following is necessary if your home on the server runs on a file system that
does not support sockets. Add this one setting to your
/etc/xpra/xpra.conf, thanks antoine!). Replace the string
by your own user name on the local machine.
Once variable expansion is implemented,
you can indeed also edit
/etc/xpra/xpra.conf and define a generic per-user
Server: Patch Screen configuration
The following lines need to be added to your
~/.screenrc on the server.
(Create the file if it does not exist.) It will start an instance of
that uses the preconfigured
Screen window 9. (Even if xpra were able to choose the
we could not let it do so because
screen, the parent process, needs to know the value of
Test this by
sshing into the remote machine again. Now, window 9 should
contain logging information from xpra.
Client: Connecting to the server
The final piece is the command that needs to be run on the client to connect to a remote xpra session:
This will attach to your (only) xpra session running on the server, and works even with a changed socket dir thanks to the changed xpra configuration. This command must keep running as long as you want to use GUI applications on the remote machine.
Test this by starting a GUI application from inside the remote Screen.
Client: Connector script
We can wrap this with a script that will also set the window title and accept the host name or address as parameter:
Add or link this script to some location in your
Watch out for lonely
Xvfb processes using
pstree $USER, sometimes killing
xpra doesn't kill the associated virtual framebuffer.
It's only a bit of configuration, but I understand that coupling xpra with an
auto-started Screen might not suit everyone's needs. Packaging this into a small
application that works similarly to
keychain (a script that determines the
current state, starts xpra as daemon if necessary and creates sourceable files
which are then sourced from
.bashrc) would be a logical next step.