Forum Replies Created
-
Posts
-
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
Hello.
The problem is with starting of nxclient –monitor process.
Unfortunately it is started as standard user and the logs will be saved in the home directory.From the main logs the path in this case should be ‘C:\Users\Disaster\.nx\’
Just to be on the safe side please send us the whole ‘.nx’ directory to the same address.
/Mth
Hello
These errors should not be the cause of delay, they are from procedure that is started after the switch is detected.
Most likely right now there is no way to speed it up.
/Mth
Hello.
Yes the facts are pointing to the nxserver –daemon process that is responsible for physical session detection is somehow broken at machine startup.
There are no differences in how we check the running sessions, so the only thing that is different should be the context the nxserver –daemon is started with.
There is a faint possibility that during the Arch update and rollback that you mentioned the NoMachine service file was corrupted, did you perhaps try to reinstall NoMachine afterwards?
In any case we probably will need to investigate this further, could you provide more information about the OS setup that may be relevant? E.g. was there any custom pam.d modifications made? Is there any antivirus software running or any centralized user database like Active Directory configured? Or any unconventional services running on startup?
/Mth
Hello
So this looks fine. There are two possibilities either something is wrong with user ‘nx’ and access to the ‘ss’ command on login window,
or the problem is that nxserver process that runs it is started too early on the system startup and does not fully initialize.Could you please run the following command like before – via ssh
when system is in login window:sudo su nx -s /bin/bash -c '/bin/ss -lnx'and see if there are any problems.
/Mth
Hello.
The logs indicate that nxnode process that is responsible for physical session is terminating with segfault. It is either system segfault or our abort procedure, we are not sure.
Please check the system logs for nxnode process with pid 11286. If there are any crash reports we would be grateful for a backtrace.
Also please include the rest of log files from our log directory besides the nxserver.log. We would require the nxerror.log and the node directory.
/Mth