Persistent Remote X

Goal

Sometimes one needs to run a program on a remote computer. While "remote computing" is very well established since ages it might be a challenge in itself.

If that program should continue to run when you turn off your local computer (the client) it gets more complicated. By design it is possible to run programs on a remote computer, even when the network connection is not reliable or a users logs off at the local system.

For this to accomplish we need several bricks to build a working system. Unfortunately some of the necessary bricks are inconvenient and others have some quirks.

This page describes how to prepare a remote computer and use a long running program with graphical output. To make it even more complicated we use ssh double-hop to reach the pseudo-server machine in our pool.

Warning: please note that our pool is not a compute-pool. Machines may get shutdown without further notice.

Precondition

• a local X-Server. Any Linux and also XMinG on Windows qualify. Alternatively a VNC Client is sufficient.
• valid credentials to access a computer in the pool

We will use three independent shell sessions. Do not mix them up!

Session 1 - Start X Server

Go to any powered on pool computer. From outside Goenet this requires you to go through "login.stud...".

ssh gtest2@login.stud.informatik.uni-goettingen.de
ssh c004.cip.loc

Start "screen" as a detachable proxy. Please learn how to use "screen", read man screen - it is essential for this tuturial. Valid alternatives are TMux and/or Byobu.

screen

On the first run we need to create a password:

vncpasswd   # creates a hashed  ~/.vnc/passwd 

Pitfall: vncserver does not work on our systems:

|vncserver 
|vncserver: Wrong type or access mode of /afs/informatik.uni-goettingen.de/user/g/gtest2/.vnc.

But there is a another (though not so convenient) way. To use the password-file and start a display on an arbitrary chosen display number:

Xvnc -PasswordFile .vnc/passwd  :23 
Xvnc Free Edition 4.1.1 - built Feb  5 2012 20:06:55
Copyright (C) 2002-2005 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.
Underlying X server release 40300000, The XFree86 Project, Inc
Thu Aug 22 13:09:09 2013
 vncext:      VNC extension running!
 vncext:      Listening for VNC connections on port 5923
 vncext:      created VNC server for screen 0

Note the line ending "port 5923". This port needs to be accessible from a client. The 23 corresponds to DISPLAY:23.

We might have added "&" the the above command to run it in the background. But because we are using "screen" this is not necessary. Leaving it running in the foreground gives us live error messages on this console! So go and get a new console by telling "screen" to create one:

Ctrl-A c

On this console we can now start X-programs. To know which DISPLAY we are talking about we set the environment variable:

export DISPLAY=:23

A definitely very useful idea is to start a window manager:

aewm &

And - just for example - a Terminal:

xterm &

(Please note that this manual way to start applications is not the "normal" way. Search for .xsession, .xinit or "X Invocation" for other ways.)

We now detach (not CLOSE) this screen session:

Ctrl-A d
logout

All network connections are terminated. But our programs continue to run!

Session 2 - Establish Port Forwarding

The first attempt to do one laaaarge step fails:

ssh -L 12345:localhost:5923 gtest2@login.stud.informatik.uni-goettingen.de ssh -L 5923:localhost5923 c004.cip.loc

There is no (second) password prompt and Port Forwarding fails.
So we need to do it in two distinct steps: Forward one local port to login.stud:

gtest2@login:~$ ssh -L 5923:localhost:4923 c004.cip.loc

For some unknown reason (did not investigate) we need to renew out credentials:

kinit && aklog

Leave this session established for now.

Session 3 - Use X via VNC

On your local system - which has an X-Server running - you may now connect to the VNC connection of your remote X:

vncviewer localhost:12345

Because this is a VNC-connection your may use UltraVNC or any other VNC client - especially on Windows or other strange Operating Systems.

Problems and Pitfalls

• the OpenAFS Token expires every day - your long-running process will lose file-access-rights. You might renew it by issuing kinit && aklog at any time.
• the Pool Computers shut down at night automatically if there is no interactive user logged in. If Xvnc through "screen" counts as "interactive" needs to be tested.
• aewm is not fully configured as this is not the "normal" way to use our computers. Please ignore errors like "font not found" or "application xyz not found".
• the pool computers are shared resources. Be kind to each other. Also any local pool user might shutdown a system by using the power switch...

See also

• Long Running Processes -- MUST READ
• Remote Access
• Xming
• PuTTY

Links

• ...