Forum Replies Created
-
Posts
-
Hello
Thank you for reporting this issue. Unfortunately the logs you provided are not conclusive.
To investigate it further we would require the content of .nx directory from home
directory of the user you are logging in with NoMachine player.Please use to collect logs:
https://knowledgebase.nomachine.com/DT11R00182Please use the part 1: Short Instructions, but after enabling logs (point 1), please run:
/etc/NX/nxserver --restartAnd following this should automatically generate the archive with everything we need.
Additionally please check the /usr/NX/etc/node.cfg file on the server machine
and provide us with the value of DefaultDesktopCommand key./Mth
Hello.
The restart of nxserver service was a proper solution to this issue. When something goes wrong with access to physical desktop, the nxserver
tries to restart the process responsible for mirroring the display up to 10 times, then it will block the physical access until the issue is resolved.In this case restart is a proper way to regain access to physical desktop, especially if the issue was an exceeded process limit, it may have left the
NoMachine instance in an unusable or broken state./Mth
Hello,
From the logs, the login window seems to be running on Wayland.
Since the machine is virtual this may be a problem for our standard capturing method.Our agent reports this exact problem:
848098 848124 18:36:58 426.520 WaylandPoller: ERROR! Grabber init failed.
848098 848124 18:36:58 426.530 WaylandPoller: ERROR! Grabber creation failed.
848098 848124 18:36:58 426.533 WaylandPoller: ERROR! Init failed.The fix for this would be either disabling the Wayland from both desktop manager (gdm) and desktop itself, or if you wish to keep Wayland please follow our article about this problem:
https://knowledgebase.nomachine.com/AR04R01083
I am not sure why it has suddenly become a problem after update, but it was either that Wayland was previously disabled and enabled by default on update, or our fix was overwritten by updated files: the egl-capture function provided in the article modifies desktop manager config file, so any update would most likely break it again.
Please let us know if this works, or if you have any other questions.
/Mth
Hello,
The SSH access to the server machine with an account having sudo privileges is required to do any administrative tasks with NoMachine.
I would suggest you do the restart procedure as it will potentially clean up some leftovers from the failed startup procedure.
Command to restart the server:
sudo /etc/NX/nxserver --restart/Mth
Hello.
This seems different than the topic you mentioned.
In fact the logs from the agent suggest this is the issue with Wayland:
3706049 3706070 16:28:17 661.940 DrmGrabber: ERROR! DRM init failed.
3706049 3706070 16:28:17 665.154 WaylandPoller: ERROR! Grabber init failed.We have an article to follow in this case:
https://www.nomachine.com/AR04R01083 (“Connecting to a Wayland-based desktop running in a Linux virtual machine”)
Please try the options here. I would suggest trying the “Option #2: Use EGL capture” first,
as this right now should be the most reliable way. Please note this way modifies the display manager,
so it would be necessary to restart it as pointed in the article and it may be inconvenient to do.
In this case option #1 would be the best./Mth
Hello,
There might be a few reasons for what is happening.
The first question is, this is a headless Linux machine, but is creating a new desktop. Is it a desired thing or you have perhaps a physical session running and want to connect to it?
If it’s the expected behaviour, please check th
e /usr/NX/etc/node.cfgfile and check the DefaultDesktopCommand key if it is set to a valid application. There could also be a hint in the system logs. Please check if there are some mentions of this application there.Another reason might be if the DefaultDesktopCommand application has been updated and stopped being compatible with the default configuration. In this case, we would be happy to see the logs.
Please follow the article on how to enable debug: How to gather debug logs for support requests
Then please do:
sudo /etc/NX/nxserver --restartGather the logs either manually or by executing:
sudo /etc/NX/nxserver –debug --collectPlease send the logs to forum[at]nomachine[dot]com using the title of this forum’s thread as the email’s subject.
/Mth
Hello
Yes it is not platform dependent issue and it may happen on install everywhere. It should be resolved in the next update, and in the meantime the workaround described here should fix it.
/Mth
Hello.
It does not seem the problem is on the NoMachine server side.
From the logs:
The user is indeed logged, the confirmation is sent to the player, but nothing else happens, not even closed connection. Then new connection is accepted and it hangs at the same place, there is third connection with the same fate. All three are closed on shutdown.
The problem then seems to be either on the network or on the player side.
Could you please provide the logs from the player? The instructions are in the same article, paragraph “Fourth Step: Collect Client Side Logs”
/Mth
Hello,
Sorry for a bit of confusion, indeed there was no running Xserver, but since you mentioned the DefaultDesktopCommand key I was certain that this is intended and what you need is to make the “desktop on demand” to work.
This is what was happening:
1. NoMachine was detecting no Xserver running.
2. After connecting to the server NoMachine tried to run “desktop on demand”
3. The desktop on demand was failing because of nxnode process crash.Desktop on demand is basically a virtual session started by NoMachine in case there is no physical Xserver running, so fixing lack of Xserver would fix it, if it is the only problem.
To summarize, if this is enough for you to make this work, it’s OK, but please remember there is some more serious problem there with starting virtual session, so please let us know if you need assistance with debugging this issue.
/Mth
Hello.
We have a warning in the logs:
23792 23792 2021-01-22 04:10:01 648.368 NXSERVER WARNING! Process ‘/usr/NX/bin/nxexec –node –user janiedp –priority realtime –mode 0 –pid 43’ with pid ‘24201/24201’ finished with exit code 1 after 0,359 seconds.
This means the nxnode process for user ‘janiedp’ fails immediately after launch. This looks like a known issue described here:
https://www.nomachine.com/TR12R09991
Please check if the nxerror.log file in the ‘<user home>/.nx’ directory contains the errors similar to the ones described in that document:
23813 23813 16:55:23 743.409 File: ERROR! Can't lock FD#7 with mask 0x5. 23813 23813 16:55:23 743.506 File: ERROR! Error is 9, 'Bad file descriptor'. Error: Cannot lock log file '/home/user01/.nx/nxserver.log'Where <user home> is home directory for user ‘janiedp’. If yes, the workaround for this problem is described in the same document.
Please let us known if it helped the situation or, if it don’t, please send us the logs from ‘<user home>/.nx’ directory.
/Mth
Hello.
The problem here is that nxnode process we start to run the session dies with signal 11.
29393 29393 2021-01-22 18:06:21 322.548 NXSERVER WARNING! Process '/usr/NX/bin/nxexec --node --user katherine.dadamo --priority realtime --mode 0 --pid 29 -H 4' with pid '29987/29987' finished with exit code 11 after 1,490 seconds.Please check if there are any crash reports regarding ‘nxnode’ process, we would be interested in
seeing the backtrace.Also it seems that in node.cfg there is a key set: EnableSyslogSupport = ‘1’
It means that nxnode process logs will go to system logs instead of NoMachine logs.Please grep the system logs file by keyword “NXNODE” and send us the results alongside the
backtrace from crash report if it exist.If You have problems with crash report, please use the following article:
https://www.nomachine.com/AR09L00810
/Mth
Hello,
The problem seems to be that there is no local node added to the database.
The corresponding log in nxserver.log would be:
11735 11735 2021-01-20 17:09:17 933.984 nxserver local node is not in the database, skip find X servers.
The local node should be in the database by default and since you have a workstation license and removing
the local node is impossible, most likely there is a bug in the install/update procedure.You could use the following command:
sudo /etc/NX/nxserver --addtoredisto initialize the database.
I can see the logs from install and update, but only for version 7.0.211. Please let us know if you had any other NoMachine versions installed previously, so we could pinpoint any update problems.
/Mth
Hello.
If this is default Ubuntu installation it is possible that even if it has disabled Wayland on desktop, it will still be enabled on Login Window. This may be the issue here as NoMachine
cannot reliably capture screen on virtual machines that use Wayland by default.Please check if the Wayland is enabled on the Login Window.
If it is enabled please follow the article:
https://www.nomachine.com/AR04R01083 (“Connecting to a Wayland-based desktop running in a Linux virtual machine”)
Disabling the Wayland from Login Window is also valid here, as it is not really impacting the system much.
If it is disabled, NoMachine should be working by default there, so we would require logs from the server machine to investigate this problem further.
Please follow the article on how to enable debug:
https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)
Then please do:
sudo /etc/NX/nxserver –restart
Gather the logs either manually or by executing:
sudo /etc/NX/nxserver –debug –collect
Please send the logs to forum[at]nomachine[dot]com using the title of this forum’s thread as the mail’s subject.
/Mth
Hello.
At first glance this looks like a known issue described here:
https://www.nomachine.com/TR12R09991
The nxnode we create for user ‘fst’ fails immediatelly.
Please check if the nxerror.log file in the ‘<user home>/.nx’ directory
contains the errors similar to the ones described in that document:23813 23813 16:55:23 743.409 File: ERROR! Can't lock FD#7 with mask 0x5. 23813 23813 16:55:23 743.506 File: ERROR! Error is 9, 'Bad file descriptor'. Error: Cannot lock log file '/home/user01/.nx/nxserver.log'If yes, the workaround for this problem is described in the same document.
Please let us known if it helped the situation or, if it don’t, please
send us the logs from ‘<user home>/.nx’ directory at the same address as before./Mth
Hello.
The logs suggest that there is still problem with wayland and pipewire.
Since the forum post you mentioned we have changed the Wayland handling, so I would suggest to revert the change you made: edit the /usr/NX/etc/node.cfg config file and comment the key:
DisplayServerExtraOptions "-wlmode compositor"or remove the “-wlmode compositor”
Then please follow the article:
https://www.nomachine.com/AR04R01083
on how to enable Wayland capturing.
Please let us know if there are any problems with this solution.
/Mth