- This topic has 4 replies, 3 voices, and was last updated 3 years, 12 months ago by
.
-
Posts
-
Dear community,
I am using the latest enterprise version (‘nomachine-enterprise-desktop_6.9.2_1_x86_64.rpm’) on a CentOS 6.10 machine, to which I am connecting from macOS 10.15.4, using the free version (also 6.9.2_1). Protocol is SSH, authentication is done with username and password on the server, after which I am accessing my gnome desktop via the usual graphical login. This often works, but I am seeing seemingly random disconnects shortly after this graphical login; if this happens, I am unable to re-connect because the client indicates it is “waiting for desktop user to authenticate the session” (or similar). Reconnecting to the running graphical gnome session does work after restarting the nx server. Another strange observation is that after logging out from the gnome session, it always takes quite a while for the login screen to re-appear.
After this happened several times, I inspected the nx server logs. Indeed, nxserver.log has a _lot_ of warnings and errors.
Examples for a failed login:
NXNODE WARNING! Process ‘/usr/bin/pactl load-module module-cli-protocol-unix socket=/usr/NX/var/run/nxdevice/D-{…}/audio/cli.socket’ with pid {…} finished with exit code 1 after 0,028 seconds.
…NXNODE WARNING! Could not load module native with name: /usr/NX/var/run/nxdevice/D-{…}/audio/native.socket.
…NXNODE ERROR! Session monitor: cleaning session files: cannot remove directory /usr/NX/var/log/node/C-{…}/devices: Directory not empty
…NXSERVER User {username} from {IP address} logged out
The upper (audio related) messages may be irrelevant, but the “directory not empty” error certainly is not, and the final forced logout is what appears as an unwanted disconnect.
When logging out from the desktop session, nxserver.log shows messages like:
NXNODE WARNING! NXClientMonitor: NXClient –monitor exited with code 0. Restarting nxclient –monitor.
NXSERVER WARNING! Timeout of 10 seconds reached for terminating of node process with pid {…}.
NXSERVER WARNING! Killing node process with pid {…}.
NXSERVER WARNING! Process ‘/usr/NX/bin/nxexec –node –user {username} –priority realtime –mode 0 –pid {…} with pid {…} finished with exit code 9 after 432,809 seconds.
NXSERVER WARNING! {…} nxnode died with exit code 9.
… and a lot more about obviously uncleanly terminated processes (again audio related as it seems).
The /usr/NX/var/log/node directory holds a lot of subdirectories named “F-C-{server}-{session id}”.
I should mention that the installation on the server was done without any non-default settings, the previously installed free version had been removed together with the /usr/NX directory.
Any ideas what may be the cause of these problems?
Are the latest NoMachine versions maybe losing compatibility with RHEL6 (and derived) distributions?
Or is there anything conceptually wrong with using the graphical login screen as on the physical machine?Many thanks in advance
Hello
This is a strange behavior indeed, and should not be connected with the CentOS itself. There should be full compatibility between NoMachine
and RHEL-derived linux distributions.There is not much clues from the errors you sent as what could be wrong here, but the most worrisome part is “Timeout of 10 seconds reached for terminating of node process”.
The closing of node process is usually matter of milliseconds, and this could mean that something hangs there. The frequent disconnects may be connected.The main question would be what desktop environment and desktop manager are you using? Any other software that could interfere with X servers or file systems? Like working frame buffers, virtual machines, directory services etc.
“waiting for desktop user to authenticate the session” is a very specific message. It should only appear when the physical desktop user does not match the user you
authenticated as from the NoMachine player application. This may indicate something is running in the background that we mistake for the active session and has different user as owner. Or other underlying problem.You can try to mitigate it by setting your account as NoMachine administrator. This should at least cause this desktop owner mismatch not to happen.
You can do it by running:/etc/NX/nxserver --useredit <username> --administrator yesIn any case this looks like a problem for our developers to take care of.
Would you be willing to provide us with the full logs from the NoMachine?Article on how to collect logs:
https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)
Please enable the debug and then do
/etc/NX/nxserver --restartYou can use the command
/etc/NX/nxserver --debug --collectafter the restart for NoMachine to automatically collect and pack the logs.
Please send the logs to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.
/Mth
Dear Mth,
thanks for the prompt reply.
The machine in question runs the default gnome 2 via gdm, nvidia quadro graphics, a kvm hypervisor (no running virtual machines) — nothing special really. Monitor is switched off, in case that matters for the behaviour of the X server.
I should stress that the “waiting for desktop user” message only appears when I try to reconnect after the connection has crashed; in this situation the physical desktop session is open but I am not recognised as the same user any more. After restarting the nx server this problems is solved, and I can connect to the (still running) desktop session directly, i.e. without supplying username/password to gdm again.
In the meantime I have investigated further and, for comparison, installed the same NoMachine version on a local CentOS 6.10 machine next to the macOS client. On this machine, I can reproduce the majority of warnings and also the “directory not empty” error. In fact the latter appears on every login (on both servers) and — contrary to my initial suspicion — is not indicative of the imminent crash/disconnect. These warnings/errors seem to be related: Loading some audio-related module(s) fails, and directories in /usr/NX/var/log/node are found not to be empty since they retain /devices/audio files. So I believe this is specific to CentOS 6, not to an individual machine.
The message referring to a 10-sec timeout, however, is not a regular symptom, in fact I now realised that it appeared only once in the log. What is absolutely reproducible, however, is the long delay between logging out from the graphical session and re-appearance of the gdm login screen. On the physical display the login screen appears immediately, but on the NoMachine client it takes many seconds (15?). This happens when connected from macOS to either of the two CentOS machines, and also between the CentOS computers.
Overall I tend to think the many audio module-related warnings and the “directory not empty” errors should be readily reproducible on every EL6 machine. I am happy to provide logs as soon as the disconnect happens again.
Best regards
ohw2020After extensive and painful testing on my home setup I can report the following:
As indicated in my previous post, a lot of error messages are related to loading of audio modules. Indeed, after disabling audio in node.cfg (AudioInterface disabled) the logs look much cleaner. Personally, I don’t have any use for audio via NoMachine at all, I just need the graphical desktop.
The long delay for gdm to re-appear is still evident; it may be related to these lines which repeatedly appear in nxerror.log
... HostWmRunningHelper: WARNING! Failed to open display ':0'.... HostRead: WARNING! Descriptor FD#8 is invalid.I still see sporadic messages of the following kind in nxserver.log:
NXSERVER WARNING! Node localhost:4000 from session {...} reported: Session with pid '{...}' terminated unexpectedly.… and directories of type F-C-{…}-{…}-{…} keep accumulating in /usr/NX/var/log/node.
All of the above may appear as log noise since from a naive user’s perspective things seem to work reasonably. But looking more thoroughly the current version appears to have some flaws at least with this linux version.
Still checking for disconnects …Send us the full set of logs from the server side and we can take a look to see what’s happening. We’re not able to reproduce this behaviour which is very strange, as Mth suggested.
Follow the instructions here https://www.nomachine.com/DT10O00163 and then submit them to forum[at]nomachine[dot]com making sure you put the title of the topic as the subject. Thanks!
Closed because the user did not provide further feedback. Please notify us if you confirm that it is resolved or open a new topic if you have the same problem.