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.
@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.