Forum Replies Created
-
AuthorPosts
-
fra81ModeratorCan you clarify what is crashing exactly? A system process or the NoMachine server? Is there a crash report to share with us?
Please also gather the logs as explained in https://kb.nomachine.com/DT08U00298#1. Also the journalctl output can be useful. You can send all of that to forum[at]nomachine[dot]com.
fra81Moderatorit looks like you still have the WaylandModes key in /usr/NX/etc/node.cfg set to ‘drm,egl,compositor’. Please try to restore it to its default value (WaylandModes egl,drm,compositor) or comment it out altogether. In version 9.1.24 all known issues with the egl mode were fixed.
If that doesn’t solve the problem, please collect a new set of logs after having restored the key to the default value. Also tell us whether the server machine is headless or its monitor is turned off. In that case, does anything change if you connect a monitor or turn it on?
fra81ModeratorHi,
that’s strange. Kubuntu 25.04 works well in all our tests with version 9.1.24. Is it possible that you didn’t reboot the server after updating NoMachine? This would be necessary to make sure the new libnxegl library is preloaded. Logging out should be enough but rebooting is the safest option.
If that doesn’t help, please gather server logs as explained in https://kb.nomachine.com/DT08U00298#1. You can send them to forum[at]nomachine[dot]com.
fra81ModeratorHi Joe,
we would need to see the backtrace from the core file. You can find all the instructions here: https://kb.nomachine.com/AR09L00810
Server side logs can also be useful: https://kb.nomachine.com/DT08U00298#1.1
You can send all of that to forum[at]nomachine[dot]com, by referencing this topic.
fra81ModeratorIt’s probably because you have to edit it as a privileged user. Anyway, you can simply open a Terminal and paste this command there:
echo 'DisplayServerExtraOptions "-nosckgrab"' | sudo tee -a /Applications/NoMachine.app/Contents/Frameworks/etc/node.cfgThat will do the trick. Then you have to restart the NoMachine server with this command to apply the change:
sudo /etc/NX/nxserver --restart
fra81ModeratorHi pupu,
since I suspect the root cause may be the same, please retrieve the same information that was asked by Bilbotine in this post: https://forum.nomachine.com/topic/black-screen-connecting-to-rocky-linux-9#post-54100. Do that after going to back to the original situation that was giving you the crash.
Thank you in advance for your help.
fra81Moderator$ sudo getcap /usr/bin/kwin_wayland
/usr/bin/kwin_wayland cap_sys_nice=ep
Do you still have this after installing version 9.1.24? It is possible that system updates restored the problematic capability. Can you try to restart the NoMachine server (sudo /usr/NX/bin/nxserver –restart) and run the same getcap command again?
June 30, 2025 at 10:26 in reply to: Display issues with floating window mode after upgrading to version 9 #53627
fra81ModeratorHi,
this is a known issue. It’s tracked here:
https://kb.nomachine.com/TR06W11363
The fix will be released in the next update of version 9. In the meanwhile, you can use the workaround indicated in the Trouble Report.
fra81ModeratorHi Dick,
your issue looks like this Trouble Report:
https://kb.nomachine.com/TR10U11031
For now, you can disable Wayland as a workaround.
fra81ModeratorHi,
can you please run these 3 commands in a terminal on the server and show us the output?
1
echo $LD_PRELOAD2
ls -l /etc/xdg/plasma-workspace/env3
sudo getcap /usr/bin/kwin_wayland
fra81ModeratorHi,
thanks for the logs. Can you please run these 3 commands in a terminal on the server and show us the output?
1
echo $LD_PRELOAD2
ls -l /etc/xdg/plasma-workspace/env3
sudo getcap /usr/bin/kwin_wayland
fra81ModeratorIt runs damn slow! Seems like there was no use of the graphics hardware at all.
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.
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.
This error is due to the problem described in https://kb.nomachine.com/TR12T10706 and is unrelated. As stated in the Trouble Report, it occurs if you enable VirtualGL globally and you use vglrun at the same time. These 2 methods should be used alternatively.
fra81ModeratorSorry for the delay. We didn’t reproduce this behavior with KDE Plasma or any different environment. It has to be something specific in your system.
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?
You may try to look for the variables set by NoMachine in the env, e.g. NX_CONNECTION.
fra81ModeratorHi,
sorry for the delay. We have finally reproduced this issue in our labs. Can you confirm that it only occurs when using KDE with Wayland? To check that, you can use X11 option instead of Wayland in the login screen of the problematic VM.
fra81ModeratorManually setting the LD_PRELOAD variable to “/opt/NX/lib/libnxegl.so” does not ‘fix’ the virtual session.
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.soYou can try to set it manually and check again.
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.
-
AuthorPosts
