Windows systems use mostly GUI programs, with a few command line programs (such as netstat). Linux, on the other hand, uses mostly command-line programs, but also has gui programs (such as jvisualvm). But sometimes opening a gui program in Linux will report an error, and sometimes there is no problem. This article explores what the X Window System is and how to properly open Linux gui programs in ssh terminal.

1. Introduction

In my work, I came across the localized Damon database, which provides a graphical management tool manager. It is easy to open the management tool for Damon installed on Windows, you can find the manager management tool directly in Start->All Programs; while for Damon installed on Linux, you need to find the tool directory in the installation location ( For example, the full path /home/dmdba/dmdbms/tool) and execute . /manager, and if you are lucky, you will be able to bring up the Damon manager GUI.

The reason why I say here: if you are lucky you will be able to bring up the Damon manager GUI is that connecting to the same Damon server can sometimes open the manager management tool successfully in a Linux SSH terminal, and sometimes it will report an error. For example, if you use putty to connect to the Damon database server and execute . /manager will report an error; using MobaXterm to connect to the server and executing . /manager to the server, and it will successfully pull it out.

In fact, before understanding DISPLAY SERVER, we didn’t find out that connecting with different SSH clients is the difference between success and failure of opening Damon manager tool. Here in advance, open Damon manager with putty and MobaXterm respectively, the former fails and the latter succeeds because the latter comes with X DISPLAY SERVER and opens X Forwarding function.

The phenomenon is that sometimes the graphical management tool of the manager can be opened from different SSH terminals, and sometimes it fails (background error). What is the problem?

To abstract the problem a bit, the Damon manager running on Linux is actually a Linux gui program, so the question is how to open the Linux gui program correctly on SSH terminal? After some inquiries, I found that it is a blind spot of knowledge DISPLAY SERVER.

2. linux gui programs and Window System

What is the relationship between the graphical presentation of Linux gui programs and the Window System?

2.1 Window System

It is easy to open graphical applications on Windows systems because the graphical capabilities of Win programs are written in the kernel (Microsoft discovered the great commercial value of graphical interfaces after the DOC system and later developed operating systems that support graphical content at the kernel level). Linux (or POSIX) systems that want to support graphical interface programs need Window System (one of the philosophies of Unix systems is that a tool does one thing and does it well, so graphical displays are architecturally decoupled and independent as well).

The Window System is a gui that implements the window, icon, menu, and pixel-dot paradigms, and most of the familiar Unix operating systems use the X Window System, and Apple’s OSX system uses the Quartz Compositor Window System.

Note that Window System here is not Windows System and is not related to Microsoft windows.


The core of the Window System is the DISPLAY SERVER (also called window server, compositor). A program that calls DISPLAY SERVER to display a graphical representation is called a client (client) of that DISPLAY SERVER.

There is both a client (a gui program that calls the DISPLAY SERVER service) and a server (the DISPLAY SERVER), and their interaction involves a protocol, which is called the display server protocol. The current protocol used by the X DISPLAY SERVER of the X Window System is X 11 (11 means version).

The main function of DISPLAY SERVER is to coordinate input and output between the operating system, hardware and other modules and the gui application, providing an abstraction on top of the graphical hardware for use by higher-level graphical interfaces such as window manager.

2.3 How Linux gui programs present graphical interfaces

The Window System is designed to be hierarchical, which reflects the design philosophy of the Unix system. The Window System graphical call architecture is as follows.

Window System

As you can see, DISPLAY SERVER is the heart of the Window System. When you open a gui program on Linux, it calls the DISPLAY SERVER graphical display service. At this point DISPLAY SERVER is the server, and the gui program is the client. Here there is a difference with our usual understanding, we usually think that the server is on the remote side and the client is on the local side, here the call of DISPLAY SERVER service is the other way around (the remote side calls the local side, that is, the GUI program calls DISPLAY SERVER).

So where exactly is DISPLAY SERVER located locally?

It could be in your local Linux operating system, or it could be manually installed in Windows (which doesn’t have a display server service by default), or it could be provided by a built-in ssh client tool (such as MobaXterm), etc. But all in all, if you want to start Linux gui locally, you must have the DISPLAY SERVER service locally.

How does the Linux gui program find the DISPLAY SERVER service?

The environment variables in the program startup look for the service address set by DISPLAY. For example.

EXPORT DISPLAY=:0.0 means that the local DISPLAY SERVER service is called on port

EXPORT DISPLAY=:10.0 means the local DISPLAY SERVER service is invoked on port

EXPORT DISPLAY= means call the non-local (but local) DISPLAY SERVER on port

By “local”, we mean the host set by the environment variable, which may be a local host, a local virtual machine, or an ssh remote remote host. “Local” refers to the local host.

The actual DISPLAY SERVER service listens on port number is the first number +6000 after setting the environment variable :, as in :3600.0 above the actual service listens on port 6000 + 3600 --> 9600. After configuring the DISPLAY environment variable, you can use xhost + to verify and disable the Access Control restrictions.

Some Linux servers see echo $DISPLAY set to :0.0, but can’t find the corresponding X SERVER listening service via netstat -nalp |grep 60000, so the X SERVER can only open the local gui program normally, remote other host and configure the current machine export DISPLAY=x.x.x.x:0.0 of the DISPLAY attribute does not tune through the X SERVER service. If the local X service is listening through the port view, the remote host configuring the local X SERVER is able to invoke the X SERVER service and open the gui program.

X11 Forwarding and DISPLAY environment variable settings are two concepts; DISPLAY is telling your environment where to call the X SERVER service, while X11 Forwarding can forward the locally configured DISPLAY SERVICE to the X SERVER where the Forwarding service is started.

When using MobaXterm to connect to a remote server, this ssh client automatically starts an X DISPLAY SERVER service and turns on X11 Forwarding to ensure that you always have the Linux GUI program open correctly. This is why the two ssh client tools have different results when opening the same Linux GUI application, as mentioned at the beginning of the article.

The common DISPLAY SERVER is as follows.

  • X.Org server (mostly for unix like)
  • Wayland (mostly for unix like)
  • Mir (mostly for unix like)
  • SurfaceFlinger (This is for Google Android)
  • Quartz Compositor (This is what Apple MacOS uses)
  • Desktop Window Manager (This is what Microsoft Windows uses)

3. Open Linux gui programs with Microsoft VcXsrv

Windows graphics are supported by kernel programs, so Windows does not have DISPLAY SERVER by default. If we remote Linux machines and open Linux gui programs locally in Win, we need to install DISPLAY SERVER, the DISPLAY SERVER used here is X DISPLAY SERVER or called X SERVER.

Windows often use X SERVER are XManager, MobaXterm X SERVER, XMing and so on. MobaXterm starts an X SERVER on the local port 6000 by default (port 6000 is also the default port for X protocol:0) and enables the X Forwarding feature. When remoteing Linux from windows via ssh and starting a gui program, the kernel will call the DISPLAY service configured in the environment variables to draw the GUI, the value of DISPLAY is written as IP:PORTOFFSET:0.0 and will access the X service of IP:6000+PORTOFFSET. . Let’s experiment.

A remote virtual machine with the full JDK installed, open jvisualvm, and without the DISPLAY environment variable set, will report the error.


Install VcXsrv Windows X Server on a Windows 10 system, open and configure display num to 3600 and Access Control to disable after installation, as shown here.

Install VcXsrv Windows X Server

Install VcXsrv Windows X Server

Set export DISPLAY=$HOST:3600.0 on the virtual machine and reopen jvisualvm.


At this point you can successfully open jvisualvm, a linux gui application.

Here $HOST is the IP of the Windows where VcXsrv is installed, make sure that port 9600 is connected to the virtual machine. The port DISPLAY NUM is customizable, here it is set to 3600 because the local 9600 port and the virtual machine are connected.

4. Summary

The graphical presentation of gui programs on Unix-like systems requires the support of the Window System service, the core of which is the DISPLAY SERVER. When a graphical gui program is opened, DISPLAY SERVER acts as the local called server, and the gui program exists as a local or remote client caller, and the two communicate through the display protocol. gui programs get the DISPLAY SERVER address to be called through the program startup environment variable DISPLAY. The default value is :0.0, which means that the local DISPLAY SERVER is called.

Note that.

  1. the port between the graphical gui program and the local DISPLAY SERVER service must be connected (if there is a firewall restriction, the service call will fail).
  2. After you configure export DISPALY=x.x.x.x correctly, but the gui application starts with an error that *.so library is missing, then there may be a difference in the library version. Command: ln -s /lib64/ /lib64/ Create a softlink from /lib64/ to /lib64/