Forum Replies Created
It seems that we need to do more debugging.
Please edit the file:
and add following lines:
before the last line, so the end of this file look like:
exec “$NXPath/bin/nxclient.bin” “$@”
Then please reproduce the problem with connection to Solaris and send us the nxclient
logs. This logs will be under the:
directory, where will be a new F-M-* directory created.
Unfortunately there are not really any clues in the logs, nothing specific, so we would require
additional help to solve this problem.
It does not seem the problem is connected directly with the target Solaris OS, but it is local.
First there is the failure of client –monitor, could you provide with logs from the nxclient?
For the session in your previous logs they will be in the
then we would need agent logs, for the same session they should be in:
Then some questions:
1. It seems that there is Kerberos configured on this system, could you check if there are any errors for the user ‘pozard’?
In the logs we have an error regarding that ticket, but the user directory access seems to be working so it may or may not be related.
2. When you say the XDM to Ubuntu server works, did you also use user ‘pozard’? If no, please check what happens.
3. When you try the failed session, are there any other NoMachine sessions for user ‘pozard’ running?
Unfortunately it is impossible to do what you described on the free version. We only allow for one session to run, so to be able to switch users sessions you would need to terminate before logging out, log in with another user and click “Yes”, or have the proper desktop environment running, where desktop manager can take care of user switching.
“Always create a new display on this server” is also not an option, because it will only allow for one user to have this session, and it will be always started when the NoMachine is starting.
/MthJuly 13, 2018 at 08:26 in reply to: Failed to connect to socket /tmp/dbus – Connection refused #18998
So from the messages file there is this from NX:
Jun 27 06:18:43 rgs05 nxnode: WARNING! Process ‘/bin/bash -c exec -a – /bin/bash -c ‘/etc/gdm/Xsession gnome-session” with pid ‘41015/41015’ finished with exit code 1 after 12,906 seconds.
Jun 27 06:18:43 rgs05 nxnode: ERROR! Session application terminated abnormally
So we can rule out NX processes generating problem on their own.
There can be two things to cause problems here:
1. The session wrapper ‘/etc/gdm/Xsession’. Please check if there was any modifications done to this file that could point to any problems.
2. User ‘vr044’ configuration. Could You check any unorthodox changes in this user configuration files? Especially if they are connected with gnome-session, so around in .config/gnome* or /.gnome* in this user home directory.
Unfortunately we cannot help here without the logs from server side.
You can find instructions about debug and collecting logs here: https://www.nomachine.com/DT07M00098.
Please enable the logs in server.cfg and node.cfg, then just to be sure we have everything
covered restart the NoMachine server: You can do it from NoMachine Monitor GUI. Then please
repeat the connection and send the logs to forum[at]nomachine[dot]com referring post topic in mail subject.
/MthJuly 5, 2018 at 09:36 in reply to: NoMachine refuses to re-attach to physical session #18902
Sorry for the late answer…
Yes indeed it should be working just with that, there have to be something more.
So first things, there are two different problems there:
1. NX cannot make physical session available.
2. NX fails to run desktop on demand (virtual session).
we need to handle both of those problems separately.
Problem one I’ve only seen once in the logs, then every other attempt was only NX trying to
start desktop on demand, so to reproduce this, please do the following:
1. Please make sure the key ‘CreateDisplay’ in server.cfg file is set to 0 and uncommented.
2. Please make sure the key ‘SessionLogLevel’ in both server.cfg and node.cfg is set to 7 and uncommented
# /etc/NX/nxserver –restart
4. When connecting with player and asked if it should create new desktop, please select “No”.
5. If the session list is empty, please wait a moment in case it takes longer to run.
6. Please send us the logs in /usr/NX/var/log/ directory. Preferably all of them.
7. Please check the system logs in the case the nxnode process is crashing, we would like to
receive what is logged or backtrace if present.
I hope this will give us some hint on both problems, so we would tackle the starting of virtual session next.
/MthJuly 4, 2018 at 09:17 in reply to: Failed to connect to socket /tmp/dbus – Connection refused #18864
So the nxserver.log is empty because of the configuration key EnableSyslogSupport
is set to 1 in both configuration files.
If this is the case, please provide us with the logs from the system log file accessible
via the standard syslog interface (e.g. in /var/log/syslog, can depend on configuration).
This logs can be identified by nxnode and nxserver nametags.
/MthJune 26, 2018 at 07:44 in reply to: Failed to connect to socket /tmp/dbus – Connection refused #18821
I do not know what happened, but the nxserver.log file inside the archive you sent us
is completely empty. Can you check what happened there and send us the logs again
with reproduced problem?
Please also send us the configuration files server.cfg and node.cfg from the server machine
to help investigating. Also if this user that is experiencing problems have his own
node configuration file (<username>.node.cfg), please send it too.
And question: is this user having any other processes running on this server that
can interfere with starting desktop environment? Like another desktop environment inside
a virtual frame buffer? If yes please tell us which ones.
/MthJune 21, 2018 at 15:25 in reply to: Remote from system, no physical session "New desktop" greyed out #18812
Free version of NoMachine does not support creation of virtual session except for creating one
default on demand where no physical sessions are available, but according to the logs you provided in
it also fails in your environment, so please continue with the previous topic.
/MthJune 19, 2018 at 11:46 in reply to: NoMachine refuses to re-attach to physical session #18766
Unfortunately there are still more questions and no answers there in logs.
From nxerror.log most notable entries are:
free(): invalid pointer
nxnode.bin: malloc.c:4030: _int_malloc: Assertion `(unsigned long) (size) >= (unsigned long) (nb)’ failed.
so it looks like the nxnode process is crashing.
It seems to be something caused by operating system specific reason. Maybe you can think of some
specific configuration there that can interfere with starting processes? Maybe something in pam.d
configuration or user-specific limits? We are using pam.d/nx configuration file that base on su.
Maybe there is something in pam.d/su that can cause problems, so if it is modified, please send us
what changes were made and which modules were added. Also there could be a hint in system log file
/var/log/auth.log – please look for ‘pam_unix(nx:session)’ entries.
Going back to nxnode process crash. There should be a hint for this in /var/log/syslog file or similar.
If operating system is configured to leave core files after crash we would be grateful for a backtrace
from all threads. If not, You can try configuring nxnode to run with valgrind to help us find the problem.
Please refer to our article at https://www.nomachine.com/AR09L00809 on how to set up NX to work
/MthMay 21, 2018 at 14:01 in reply to: NoMachine refuses to re-attach to physical session #18445
Regarding the logs you sent us, there is a new behavior different to the previous problems: nxexec process when starting node for desktop owner crashes. There are a few things to check:
1. In logs there are two instances: nxexec with pid 21223 and 21316. Is there any sign of nxexec or nxnode processes crashes in system logs?
2. Is there any indication of problem in our nxerror.log file. This file is located in ‘/usr/NX/var/log’ directory by default and is important part of logging. You can also send us this file for investigation. Also please check if SessionLogLevel in node.cfg file is also set to 7 as I cannot see any node logs and am not sure if the process is started or crashes on runtime.
3. Please check the access rights to ‘/usr/NX/bin/nxexec’ file. they should match:
Access: (4555/-r-sr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
4. Please check if nxnode works properly. You can check it with
If there are any errors please send us the logs again.
apologies for the late reply. I thought I had answered, but had left my message cached instead of posting on the day of you previous followup.
So there are basically three problems there.
First you seem to have run into a known bug with Xserver, when NoMachine queries for
information before physical session is started, the Xserver will get confused and not let
the physical session to be started. So the only solution is to keep the checkLocalSessionDelay
key on default – removed or commented.
Second, because of that problem, our session finding has to be delayed, and it is also a known problem, if someone tries to login before the session finding is complete, there will be a query sent to the player connecting to start new desktop. This is what happens in your logs. 5 seconds after NX
startup, there is a connection with answer “yes” to creating new desktop. The proposition here
is to answer “no” and wait for physical session to be detected.
And this come to a third problem, which is black screen after selecting “yes”, this also should not happen.
From the logs, what is started is ‘/etc/X11/Xsession default’ which exits after 6 seconds with no errors
visible in our logs. This may be related with first problem, but we have not enough data to follow on this.
Is there any problems in system logs during this time? There may also be something in .xsession-errors file in users home directory.
/MthMay 18, 2018 at 07:53 in reply to: NoMachine refuses to re-attach to physical session #18420
This is what I see in logs:
1. nxserver –daemon process is started, probably after system restart.
2. It tries to detect any running Xserver, but the command ‘netstat -ln –protocol=unix’
does not list any proper sockets.
3. Our virtual Xserver is started automatically and no more attempts to find Xservers are made.
4. Two login attempts are made, but no attach.
5. nxserver –restart is invoked and new server –daemon starts.
This time server detects two running Xservers on displays :0 and :1.
On display :0 we have running ‘gnome-session-binary –autostart /usr/share/gdm/greeter/autostart’ – so it is Login Window
On display :1 ‘gnome-session-binary’ – it is users desktop.
When queried about sessions, operating system answers that session on display 0 is inactive and on display 1 is active.
6. The attach is being made to a proper session, but it seems to hang and is terminated after around 90 seconds.
So there are two problems:
First the virtual session that is being created after system startup. Probable culprit is the order of starting services in system. NoMachine is started before Xserver is finished, and it is causing problems. This can be mitigated by disabling automatic session creation in the server.cfg file. Please set the key ‘CreateDisplay’ to 0, and nxserver will wait for the Xserver to run
or it will ask during player connection if such session should be started.
The second is the hanging during attach. There is unfortunately no clue in the logs provided, so we will require additional data.
We would need client side logs from the logging attempt when player is hanging. Please refer to the point about client logs from this article https://www.nomachine.com/DT07M00098 and send them to us like previously.
It is a very strange behavior indeed. Please help us to understand this problem.
First question, is that machine headless or runlevel 3? If not, which desktop environment
and desktop manager is in use? Also if they are running on Xorg or Wayland.
Second question is: on that problematic machine in
configuration file, do you have uncommented entry
This may cause a problem if the Xserver on the machine starts slower than NoMachine.
If that’s the case, please check if DefaultDesktopCommand key in
points to a proper session command or set CreateDisplay key to 0.
Next question is, what changes on that machine during this 30 seconds, do
physical sessions stay in login window, or there is automatic login to user’s desktop
Last thing you can try to add a key to server.cfg file:
and check if this help.
If everything fails, please provide us with full logs
. You can find instructions about debug and collecting logs here: https://www.nomachine.com/DT07M00098. Please send them to forum[at]nomachine[dot]com referring post topic in mail subject.
/MthMay 2, 2018 at 16:26 in reply to: NoMachine refuses to re-attach to physical session #18282
The problem seems to be that NoMachine cannot detect running physical session and its starting
its own virtual session. If it is nomachine-6.0.66-2.x86_64 package on Fedora 26 the most probable
cause is Wayland. As stated here:
NoMachine only recently released a version that supports Wayland, so if that’s the case an update
You can also follow the tips here on how to disable Wayland:
If this is not the case, we will need further information to properly debug this problem:
– What system/desktop environment processes are running for the logged user/login window screen.
– nxserver.log from nxserver startup. We would need only logs from nxserver –daemon process, so no logging required.