fra81

[fra81]

Hi!

I’ve never heard of a similar issue. Please collect the logs as explained here: https://www.nomachine.com/DT07M00098. You can send them to forum[at]nomachine[dot]com.

[fra81]

Yeah, that is strange. Please gather NoMachine server side logs as explained in https://www.nomachine.com/DT07M00098. You can attach them here or send to forum[at]nomachine[dot]com.

[fra81]

So it can happen, depending on the video card, that the X server is running but it is not rendering, because the video card is turned off.

You can try to stop the X server:

sudo service lightdm stop

and restart the NoMachine server:

sudo /usr/NX/bin/nxserver –restart

At this point NoMachine will create its own virtual framebuffer and you should be able to connect and see the desktop.

[fra81]

Hi,

it looks like the same problem reported here:

https://bugs.kde.org/show_bug.cgi?id=377335

I suspect the problem is related to libGL.so provided by nVidia. As a workaround, you can try to set the LD_LIBRARY_PATH in order to use the Mesa version of libGL. To do so, you have to modify the DefaultDesktopCommand key in the /usr/NX/etc/node.cfg configuration file:

DefaultDesktopCommand “env LD_LIBRARY_PATH=<directory where Mesa’s libGL.so is in> <command to start KDE>”

You can find the path to Mesa’s libGL by issuing this command:

ldconfig -p | grep libGL

For example:

DefaultDesktopCommand “env LD_LIBRARY_PATH=/usr/lib64 /usr/bin/dbus-launch –exit-with-session startkde”

[fra81]

Hello.

You can send the logs to forum[at]nomachine[dot]com.

Is your server a headless machine? Or is it running in a virtual machine?

[fra81]

Hello!

Please try to uncheck the ‘Use acceleration for display processing’ option in the NoMachine Preferences, Performance tab. You can reach them from the tray icon by clicking on Show the server status, inside your virtual machine.

[fra81]

Hello,

as for your points above:

1) Are you using proprietary nVidia drivers? You can try to send us the logs for inspection. NoMachine logs can be gathered by following the instructions in https://www.nomachine.com/DT07M00098. Also the .xsession-errors file in the user’s home on the server, if present, could be useful. You can send everything to forum[at]nomachine[dot]com.

3) Please try to disable the Fit to window mode and check if the hidden taskbar is still unreachable. It could be an effect of the scaling of the session, where the 1-pixel sensible area could be rounded down to 0 pixels. Ragarding the strange behaviours of the taskbar, we will try to reproduce them in our labs, but, if possible, a screen recording could help to clarify the issues.

[fra81]

You’re perfectly right in saying that this is not a minor issue! We are already working on it, but unfortunately it can’t be a quick fix. Video encoders don’t support such high resolutions themselves. The solution is to encode monitors in separate video streams, but this is quite a big change and it will take some time and many tests.

[fra81]

Could you provide more information:

1) What source did you update your H.264 libraries from?

2) What steps did you take to build them? (i.e. Did you build then from sources? What commands did you pass to the configure script?)

3) How exactly did you make libraries available to NoMachine (by copying them, linking…)?

[fra81]

Hello,

your problem could be similar to the one reported here: https://www.nomachine.com/forums/topic/ubuntu-desktop-freeze-on-login-if-headless. Please check if the solutions reported there are feasible for you.

Alternatively you could try to configure your xorg.conf to support the headless mode. After a quick search I found a couple of links (that I didn’t test):
http://jasonjuang.blogspot.it/2016/02/how-to-configure-xorgconf-for-headless.html
http://www.virtualgl.org/Documentation/HeadlessNV

[fra81]

Hi Markus,

sorry again for the delay. We are still unable to reproduce this issue in our labs. We just got one report from a user that observed a couple of times that all processes started consuming more CPU and everything got fixed by a system reboot. Did you try to reboot and see if the problem settles down? Or, if the affected user creates a new session, is the new one also slower than normal? And more important, are always the same users affected, or anyone can be? Could this be happening for sessions running since a long time?

Anyway I’m afraid that, after we excluded all other cases, only thing left to do is profiling the nxnode.bin process, assuming that CPU usage is really related to the problem. Unfortunately this won’t be easy, because the profiler slows down the process itself, and so it might be hard to detect when you are reproducing the problem. If you are willing to try, please follow the instructions in https://www.nomachine.com/AR09L00809, but with a different DebugOptions key:

DebugOptions “–tool=callgrind –dump-instr=yes –callgrind-out-file=/tmp/nxnode.%p.callgrind.out”

And lastly, you mentioned CentOS 7 boxes. Are they running on top of a virtualization tool? Which one and what version? This might be what is different in our tests.

[fra81]

An issue with the driver is a possibility. You can try to disable the hardware acceleration in NoMachine:

https://www.nomachine.com/AR02L00782

[fra81]

Another thing I would try is disabling UDP communication in the Edit connection tab.

[fra81]

There is a limit on the maximum resolution that encoders are able to deal with, and your setup probably exceeds the limit.

That problem will be solved when the following Feature Request is implemented:

https://www.nomachine.com/FR05N03113

[fra81]

The logs look clean (provided they are from the “bad” case).

Did you try to disable the hardware decoding on the client (Display settings tab in the player’s menu).

[Author]

Posts