ainthelp

[ainthelp]

As I see in the glxinfo output, it looks like the graphics hardware is being used. Is maybe the server headless? Or is the monitor turned off? In some cases graphics drivers slow down GPU rendering considerably in case no monitor is detected.

The system has a monitor connected. And  /var/log/Xorg.0.log  confirms that it is turned on and communicates with the system.
In addition, when I connect to the physical desktop, OpenGL is working fine and the application shows good performance.
Only in a virtual desktop the slowness problem exists.

An observation I made today: Right after a reboot, VirtualGL was also working in a virtual desktop and it had good performance! While playing around with it, suddenly it became slow. At roughly the same time, the following messages were added to ‘dmesg’:

[Thu Jun 12 12:14:56 2025] show_signal_msg: 50 callbacks suppressed
[Thu Jun 12 12:14:56 2025] libnxegl.so[5007]: segfault at 3626 ip 0000000000003626 sp 00007ffc34b692f0 error 14 in libnxegl.so[7f9e06c18000+c000]
[Thu Jun 12 12:14:56 2025] Code: Unable to access opcode bytes at RIP 0x35fc.
[Thu Jun 12 12:14:57 2025] libnxegl.so[5010]: segfault at 3626 ip 0000000000003626 sp 00007ffff9cce420 error 14 in libnxegl.so[7f5ef1b23000+c000]
[Thu Jun 12 12:14:57 2025] Code: Unable to access opcode bytes at RIP 0x35fc.

The syslog contains the same messages, plus an empty stacktrace and the information that a coredump was written. I can provide those, if useful.

 

And one further thing I noticed:
When I login to a physical desktop, the environment variable  LD_PRELOAD  is defined:

% env | grep NX
LD_PRELOAD=/opt/NX/lib/libnxegl.so

Still OpenGL is working and performance is good.
But other programs like e.g. ‘less’ complain about it:

ERROR: ld.so: object ‘/opt/NX/lib/libnxegl.so’ from LD_PRELOAD cannot be preloaded (failed to map segment from shared object): ignored.

I hope that’s not too much stuff in one posting…
Let me know if I can provide more details or do some experiments. Happy to help.

[ainthelp]

You may try to look for the variables set by NoMachine in the env, e.g. NX_CONNECTION.

Well, this part worked. I found some  NX_*  variables that are only present in virtual desktop sessions. Then I modified the system wide csh login file to check if  NX_SESSION_ID  is defined. If it is,  LD_PRELOAD  gets defined:

setenv LD_PRELOAD “/opt/NX/scripts/vgl/libdlfaker.so:/opt/NX/scripts/vgl/libvglfaker.so”

After login to a new KDE virtual desktop session, this is variable is present.
With this definition of  LD_PRELOAD  we can start the software requiring OpenGL without problem.

But…
It runs damn slow! Seems like there was no use of the graphics hardware at all.

The  glxinfo  command confirms that hardware acceleration is active. Also, the check for VirtualGL is producing the expected result:

% glxinfo | grep -i “renderer\|vendor”
server glx vendor string: VirtualGL
client glx vendor string: VirtualGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro RTX 5000/PCIe/SSE2

When I run the application prepended by  vglrun  in addition, it gives some more output.

ERROR: ld.so: object ‘/opt/NX/scripts/vgl//opt/NX/scripts/vgl/’ from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
[last message repeated 12 times]
libGL error: MESA-LOADER: failed to open swrast: /SW/Schrodinger/current/mmshare-v6.7/lib/Linux-x86_64/libstdc++.so.6: version `GLIBCXX_3.4.30′ not found (required by /usr/lib64/libLLVM.so.15) (search paths /usr/lib64/dri, suffix _dri)
libGL error: failed to load driver: swrast

I don’t know where this path from LD_PRELOAD comes from. The shared libraries I defined in  LD_PRELOAD  do exist:

% ls -l /opt/NX/scripts/vgl/libdlfaker.so /opt/NX/scripts/vgl/libvglfaker.so
-rwxr-xr-x 1 root root    7704 Jan 15 12:46 /opt/NX/scripts/vgl/libdlfaker.so*
-rwxr-xr-x 1 root root 1422544 Jan 15 12:46 /opt/NX/scripts/vgl/libvglfaker.so*

Any ideas why it is running without making use of the graphics card?

[ainthelp]

Note that LD_PRELOAD is set to a different value in the physical desktop and for a different purpose. In virtual desktops, the value you are supposed to see is:

LD_PRELOAD=/opt/NX/scripts/vgl/libdlfaker.so:/opt/NX/scripts/vgl/libvglfaker.so

You can try to set it manually and check again.

Ah, I didn’t know that.
Yes, if I manually set it to the new value for virtual desktops, the OpenGL application works!

Also the test command yields the expected result now:

% glxinfo | grep -i “renderer\|vendor”
server glx vendor string: VirtualGL
client glx vendor string: VirtualGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro RTX 5000/PCIe/SSE2

 

The OpenGL application still throws an error on start, despite that it finally starts successfully:

libGL error: MESA-LOADER: failed to open swrast: /SW/Schrodinger/current/mmshare-v6.7/lib/Linux-x86_64/libstdc++.so.6: version `GLIBCXX_3.4.30′ not found (required by /usr/lib64/libLLVM.so.15) (search paths /usr/lib64/dri, suffix _dri)
libGL error: failed to load driver: swrast

Don’t know if this could be related or is something different.

 

The question is still why LD_PRELOAD is not set, even if in the logs we see that it’s being added to the environment of the desktop process. At the moment I don’t have further ideas, we will check again in our labs with KDE Plasma.

Let me know if there is anything I can test or diagnose to support you with this.

How can I recognize a virtual desktop session in the shell? Perhaps, if this was possible we could define LD_PRELOAD accordingly in the system wide login files?

 

[ainthelp]

Many thanks, fra81, for your reply!

Yes, I also wondered why the LD_PRELOAD environment variable is undefined. I checked the system configuration with

# grep -r LD_PRELOAD /etc/*sh*

and found nothing. Neither deletion nor overwriting of this variable.

I also checked the affected user’s profile with

% grep -R LD_PRELOAD ~/.*

and only found occurrences in the command history.

Then I wondered if it may be related to the fact that we are using  tcsh  as default login shell, not  bash .
I changed one user to  /usr/bin/bash  as login shell and retried. But no difference at all.

When I connect to the physical display, LD_PRELOAD is defined and OpenGL applications are working.
Only when I startup a new virtual KDE desktop, LD_PRELOAD is undefined and OpenGL not working.
Using the  vglrun  command you provided with an OpenGL program I could verify that VirtualGL is functional. Started with  vglrun , the OpenGL application even works on a virtual display.

Manually setting the LD_PRELOAD variable to “/opt/NX/lib/libnxegl.so” does not ‘fix’ the virtual session.

I then tried to start the whole desktop via the vglrun command. We are using KDE Plasma, so I added this line into  node.cfg :

DefaultDesktopCommand “/usr/bin/dbus-launch –exit-with-session /opt/NX/scripts/vgl/vglrun /usr/bin/startplasma-x11”

But even after a reboot of the system there was no change: VirtualGL works in physical session, but fails in virtual session.

I checked for the processes and noticed that the first one started by  nxnode.bin  referred to Wayland:

% ps -lefl | egrep “3069|2964|3163|3174” | grep -v grep | sort -n -k 4
4 S username   2964  2950  4  60 -20 – 842297 do_epo 14:21 ?       00:00:15 /opt/NX/bin/nxnode.bin
0 S username   3069  2964  0  80   0 –  6058 sigsus 14:21 ?        00:00:00 – -c env -u WAYLAND_DISPLAY /usr/bin/dbus-launch –sh-syntax –exit-with-session /usr/bin/startplasma-x11
0 S username   3106  2964  1  80   0 – 299205 do_sys 14:21 ?       00:00:03 /usr/bin/pulseaudio –high-priority=no
0 S username   3114  2964  0  80   0 – 301362 do_sel 14:21 ?       00:00:00 /opt/NX/bin/nxrunner.bin –monitor –pid 3069
0 S username   3163  3069  0  80   0 – 64579 do_sys 14:21 ?        00:00:00 /usr/bin/startplasma-x11
1 S username   3174     1  0  80   0 –  6947 do_sel 14:21 ?        00:00:00 /usr/bin/dbus-launch –sh-syntax –exit-with-session /usr/bin/startplasma-x11
0 S username   3327  3163  0  80   0 – 62553 do_sys 14:21 ?        00:00:00 /usr/bin/plasma_session
0 S username   3448  2964  5  60 -20 – 59013 pipe_r 14:21 ?        00:00:17 /opt/NX/bin/nxcodec.bin

May this be related? We are using X11, because our software is not compatible with Wayland.
OTOH the session itself reported it as X11 session:

% echo $XDG_SESSION_TYPE
x11

Any further ideas? Anything else I can try?

[ainthelp]

Been there, done that.

[ainthelp]

Just for completeness sake in this thread. Did as requested and provided the logs via PM.

[Author]

Posts