Skip to content

Interactive graphical sessions with VNC

VNC provides a full graphical desktop on a compute node, which is more responsive and reliable than X11 forwarding over SSH. It is the recommended way to run graphical applications (visualization tools, GUIs, IDEs) interactively on Hyperion.

Info

VNC sessions are only available on Hyperion. Atlas EDR and Atlas FDR do not have VNC support.

The session runs inside a SLURM job, so it is confined to the resources you request and subject to the same QoS limits as any other job.

Step 1: Set a VNC password (first time only)

Before using VNC for the first time, set a password. Request a quick interactive session and run vncpasswd:

salloc --qos=test --time=00:10:00 srun --pty bash
/opt/TurboVNC/bin/vncpasswd
You will require a password to access your desktops.

Password:
Verify:
Would you like to enter a view-only password (y/n)? n

This password is stored in ~/.vnc/passwd and will be required every time you connect to a VNC session.

Warning

Choose a strong password. Anyone with your VNC password and SSH access to Hyperion can access your session.

Step 2: Submit the batch script

Save the following as vnc_session.slurm:

vnc_session.slurm
#!/bin/bash
#SBATCH --qos=regular
#SBATCH --job-name=vnc_session
#SBATCH --partition=general
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=4
#SBATCH --mem=16gb
#SBATCH --time=04:00:00
#SBATCH --output=%x.%j.out
#SBATCH --error=%x.%j.err

module load DIPC-Utils

vncserver-start

Submit it:

sbatch vnc_session.slurm

If you are not familiar with the #SBATCH flags, the SLURM reference explains each directive in detail.

Tip

For longer sessions, use --qos=long (up to 2 days) or --qos=xlong (up to 8 days). See SLURM: Partitions and QoS for limits.

Step 3: Check the log

Wait for the job to start running:

squeue -u $USER

Once the state changes to R (running), read the output file:

cat vnc_session.<JOBID>.out

You will see something like this:

==============================================================
VNC + noVNC Server Started Successfully
==============================================================

  Hostname:        hyperion-215
  VNC Display:     :1
  VNC Port:        5901
  WebSocket Port:  6081

==============================================================
Option 1: Connect via Web Browser (noVNC)
==============================================================

1. Open an SSH tunnel from your local machine:

   ssh -L 6081:hyperion-215:6081 <username>@hyperion.sw.ehu.es -N

2. Open in your web browser:

   http://localhost:6081/vnc.html

==============================================================
Option 2: Connect via VNC Client (TurboVNC, RealVNC, etc.)
==============================================================

1. Open an SSH tunnel from your local machine:

   ssh -L 5901:hyperion-215:5901 <username>@hyperion.sw.ehu.es -N

2. Connect your VNC client to:

   localhost:5901

==============================================================

The log gives you two connection options. Both require an SSH tunnel.

Step 4: Create the SSH tunnel and connect

Method Pros Cons
Web browser (noVNC) No software to install, works on any OS Slightly lower performance
VNC client Better performance, especially for graphics-heavy apps Requires installing a client

On your local machine, create the SSH tunnel using the WebSocket port from the log:

ssh -L 6081:hyperion-215:6081 <username>@hyperion.sw.ehu.es -N

Replace 6081 and hyperion-215 with the actual values from your job output. Leave this terminal open.

Then open your browser and go to:

http://localhost:6081/vnc.html

Click "Connect" and enter your VNC password. noVNC works with Chrome, Firefox, Edge, and Safari.

Windows: SSH tunnel with PuTTY

If you use PuTTY instead of PowerShell:

  1. Open PuTTY and enter hyperion.sw.ehu.es as the host.
  2. Go to Connection > SSH > Tunnels.
  3. Source port: 6081. Destination: hyperion-215:6081.
  4. Click "Add", then "Open" to connect.

On your local machine, create the SSH tunnel using the VNC port:

ssh -L 5901:hyperion-215:5901 <username>@hyperion.sw.ehu.es -N

Replace 5901 and hyperion-215 with the actual values from your job output. Leave this terminal open.

Then open your VNC client and connect to localhost:5901. Enter your VNC password when prompted.

Recommended clients: TurboVNC (best performance), RealVNC, TightVNC. On macOS, the built-in Screen Sharing app works with vnc://localhost:5901.

For more details on SSH tunneling, see the SSH tunneling section in the connection guide.

VNC connection data flow

Multiple sessions

You can launch several VNC sessions simultaneously, even on the same node. Each session gets a different display (:1, :2, etc.) and separate ports for VNC and websockify. The system keeps each session isolated automatically, so there are no conflicts between them.

Customizing the desktop

By default, VNC sessions use the system-provided desktop startup script, which launches a full XFCE desktop. No additional configuration is needed.

If you want to customize the desktop startup, you can create your own script at ~/.vnc/xstartup.turbovnc. When this file exists and is executable, it takes priority over the system default.

Warning

If your custom xstartup.turbovnc is not executable, it will be ignored and the system default will be used instead (with a warning in the log).

If you create a custom xstartup.turbovnc, make sure it includes at least:

  • A per-session XDG_RUNTIME_DIR that includes the display number, to avoid conflicts between multiple sessions:

    export XDG_RUNTIME_DIR="/tmp/runtime-$(id -u)-${DISPLAY#:}"
    mkdir -p "$XDG_RUNTIME_DIR"
    chmod 700 "$XDG_RUNTIME_DIR"
    
  • A wait for the X server socket before launching the window manager, to avoid race conditions:

    DISPLAY_NUM="${DISPLAY#:}"
    while [ ! -e "/tmp/.X11-unix/X${DISPLAY_NUM}" ]; do
        sleep 0.1
    done
    

To revert to the system default at any time, simply remove or rename your custom script:

rm ~/.vnc/xstartup.turbovnc

Expected log warnings

The VNC log file (~/.vnc/<hostname>:<display>.log) may show warnings like the ones below. These are normal and do not indicate any problem:

Message Reason
Unsupported GL renderer (llvmpipe) No GPU hardware; software rendering is used
DPMS missing / Monitor is not DPMS capable No physical monitor
Failed to import environment: Process org.freedesktop.systemd1 exited with status 1 No systemd on compute nodes
polkit_agent_listener_register: assertion failed Polkit requires systemd
Unable to inhibit systemd sleep No systemd on compute nodes
No outputs have backlight property No physical monitor
screensaver already running Harmless duplicate

Troubleshooting

Connection refused

Verify the SSH tunnel terminal is still open and that your job is still running (squeue -u $USER). Check that you are using the correct port numbers from the job output.

Session dies immediately

Most likely caused by a custom ~/.vnc/xstartup.turbovnc that does not wait for the X server to be ready. Solution: remove or fix your custom script (rm ~/.vnc/xstartup.turbovnc) and resubmit the job.

Black or grey screen after connecting

The desktop environment did not start correctly. Check the VNC log (~/.vnc/<hostname>:<display>.log) for errors. If you have a custom xstartup.turbovnc, verify that it launches XFCE properly.

ICE I/O Error or segmentation fault in xfce4-session

Multiple sessions from the same user are sharing the same XDG_RUNTIME_DIR. Make sure your custom xstartup.turbovnc includes the display number in the XDG_RUNTIME_DIR path (e.g., /tmp/runtime-<UID>-<DISPLAY_NUM>), or remove your custom script to use the system default.

Password not accepted

Reset your VNC password by running /opt/TurboVNC/bin/vncpasswd interactively on a compute node (via salloc).

noVNC shows 'Disconnected'

Refresh the browser page. Check the websockify log: cat ~/.vnc/websockify-*.log. Try a different browser.

VNC server won't start

Check the log: cat ~/.vnc/<hostname>:<display>.log. Remove stale lock files if present: rm ~/.vnc/*.pid. The next job run will automatically clean up orphaned sessions.

Port already in use

vncserver-start assigns the next available display number automatically. If the problem persists, check for orphaned processes: ps -u $USER | grep vnc.

See also

  • SLURM workload manager


    Job submission, QoS, and resource requests.

    SLURM guide

  • SSH


    Connecting to Hyperion.

    SSH setup