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 withputty
andMobaXterm
respectively, the former fails and the latter succeeds because the latter comes withX DISPLAY SERVER
and opensX 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 notWindows System
and is not related to Microsoft windows.
2.2 DISPLAY SERVER
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.
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 127.0.0.1:6000
.
EXPORT DISPLAY=:10.0
means the local DISPLAY SERVER
service is invoked on port 127.0.0.1:6010
.
EXPORT DISPLAY=172.26.18.37:3600.0
means call the non-local (but local) DISPLAY SERVER
on port 172.26.18.37:9600
.
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 vianetstat -nalp |grep 60000
, so the X SERVER can only open the local gui program normally, remote other host and configure the current machineexport 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.
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 port9600
is connected to the virtual machine. The portDISPLAY NUM
is customizable, here it is set to3600
because the local9600
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.
- 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). - 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/libxxx.so.6 /lib64/libxxx.so
Create a softlink from/lib64/libxxx.so.6
to/lib64/libxxx.so
.