X Server for Rocky?

For those of you that are familiar, I use a Linux version of Niagara N4 that works fantastic… except when using it remotely, via xrdp or TeamViewer in a “headless” (no keyboard, mouse, or monitor) environment.
If I attach a monitor, no problems, life is great…
If I am “headless”, I get a blank app GUI screen and the following error from the log:

“Cannot pre-initialize JxBrowser
com.teamdev.jxbrowser.chromium.internal.ipc.IPCException: IPC process exited. Exit code: 134”

Internet research has returned the following, “JxBrowser library can be used in the headless Linux environment, given the X server is running.”
What is this X Server and where can I use it with Rocky?

The X11 contains multiple RPM-packages in EL8. Environment group is what is usually installed initially. The selection is usually something like:

[Alma]$ dnf -q group list
Available Environment Groups:
   Server with GUI
   Minimal Install
   Workstation
   Custom Operating System
   Virtualization Host
Installed Environment Groups:
   Server
Installed Groups:
...

Lets look what environment “Workstation” contains:

[Alma]$ dnf -q group info Workstation
Environment Group: Workstation
 Description: Workstation is a user-friendly desktop system for laptops and PCs.
 Mandatory Groups:
   Common NetworkManager submodules
   Core
   Fonts
   GNOME
   Guest Desktop Agents
   Hardware Support
   Internet Browser
   Multimedia
   Printing Client
   Standard
   Workstation product core
   base-x
 Optional Groups:
   Backup Client
   GNOME Applications
   Headless Management
   Internet Applications
   Office Suite and Productivity
   Remote Desktop Clients
   Smart Card Support

One of the dnf groups that is always installed if Workstation environment is installed, is “base-x”, which includes packages:

[Alma]$ dnf -q group info base-x

Group: base-x
 Description: Local X.org display server
 Mandatory Packages:
   glx-utils
   mesa-dri-drivers
   plymouth-system-theme
   xorg-x11-drv-ati
   xorg-x11-drv-evdev
   xorg-x11-drv-fbdev
   xorg-x11-drv-intel
   xorg-x11-drv-libinput
   xorg-x11-drv-nouveau
   xorg-x11-drv-qxl
   xorg-x11-drv-vesa
   xorg-x11-drv-vmware
   xorg-x11-drv-wacom
   xorg-x11-server-Xorg
   xorg-x11-utils
   xorg-x11-xauth
   xorg-x11-xinit
   xorg-x11-xinit-session

However, I don’t think that just installing base-x is sufficient. VNC and X2Go (the latter is in EPEL) might actually have their own X11 servers – not sure. (I don’t use remote desktops unless absolutely necessary, i.e. almost never.)

Hi @tamarack829 and (a late) welcome to the forum.

As @jlehtone has pointed out, the X Server (in a nutshell - I know it’s not accurate) is the “display system” in Linux. Alongside X, there’s also “wayland” which is a more recent approach to replace X… but that’s a long and diferent story.

The key concept here with X, in the context of your question, is that it is a display SERVER.
That means, it can handle both LOCAL displays (when you attach a monitor for example) or REMOTE displays (that’s what happens when you do RDP or TeamViewer from a remote system).

Now when you remotely connect to the “server” (your Niagara thing), your RDP client basically provides an empty canvas and then tells the X server at Niagara “please display here”. In order for that to work, the X server (at Niagara) must be ready to serve.
This definitely is the case as soon as you attach a monitor to Niagara. X will be started (to create a local display session). In turn, X will be able to handle also remote sessions.

Now when you don’t have a monitor attached to Niagara, it looks like its X server either isn’t launched at all or it isn’t configured correctly to “listen for” or allow remote sessions. Unfortunately, I don’t know the X internals and config things well enough to assist in debugging or analyzing that stuff further. But it shouldn’t be too difficult for savvy people to come up with a simple solution (given that X apparently works perfectly as soon as you attach a monitor).

Nevertheless, hope this helps to some extent.
Cheers, Thomas

One more anecdote. On system, where NVidia GPU and drivers are used, the NVidia drivers have X11 setting to start even when there are no displays. The default for NVidia is to enumerate the displays and query from them resolutions. That way it finds how large “screen” to create. With no displays it does nothing and X11 server does not start.

When X2Go or similar starts a X11 server, the size of screen is decided by some other means, I presume.

There could be a number of factors limiting the remote use of X on the Niagra distro. For example in Arch linux for both remote and local root logins the x-server is disabled. A normal user is allowed to start a remote x session but escalating to root is limited to a terminal w/o GUI support. I think this is true for Debian also.
You could try typing “startx” in the remote session and see what output you get.

This is the output from startx while logged in through a remote session using XRDP.

@schroedingersdog , I don’t think it gets any more clear when you explain it like that. In the end, I found a display emulator dongle on Amazon that plugs into the display port of the local machine. Now, I can launch TeamViewer and have full, unabated access to the N4 Workbench GUI in a “headless” setup. It’s a fantastic workaround, but I am a perfectionist and I want to see if I can get this thing fully accessible from Windows RDP, as was my goal originally (2+ years ago now). Niagara is my only holdout, and it’s the most important program on this device!

If we can’t get the X Server started in a remote session, I’ll check through the forum discussions and see if anyone else has brought this up before I start another one.

Thanks everyone for your help! Rocky Linux and its community are really amazing.

So the screen shot you posted up two posts says it all.

Xorg.wrap is not allowing remote x sessions. How to disable that is distro specific.