Forum Replies Created
April 23, 2018 at 08:03 in reply to: NoMachine always starts a new user session even on disconnect #18210
This problem may be caused by the server.cfg key ‘EnablePersistentSession’
Please make sure that username ‘user’ is listed there, or it is set to the default ‘all’
value or commented. Valid key values for this case would be:
I can see no hint of it in logs, but please also make sure that the key
DisablePersistentSession does not list this ‘user’.
Please let us know if this does not help with the issue.
Such behavior is expected when trying to attach, when different user is already connected.
On the free version of NoMachine it is only allowed for just one connection at once, so if there is one
connection established, NoMachine will ask current user to disconnect and give 15 seconds to answer.
If no answer is made the old session should be disconnected regardless.
To disable this you can enable config key AutomaticDisconnection and set it to 1:
It will cause old sessions to be always disconnected immediately even when different user is logged in.
Please let us know if it solved the issue or if another behavior is observed or expected.
It seems that you have two problems here.
First one is:
The session negotiation failed.
Error: Agent was not initialized properly.
This we have reproduced and it is connected with the Xvfb process:
dslaybac 22939 1 0 Jan30 ? 01:45:10 /usr/bin/Xvfb :25 -screen 0 1280x1024x8
NoMachine doesn’t support 8bit color, so any attempts to attach to such desktop will always cause
agent not to be initialized. Changing to 24 bits should help here.
Second problem is that the nxexec –node –user lightdm process crashes with 11. We would need some more data to help with this. Can you check if the operating system is generating crash file for these and provide us with backtrace of core dump? Also the process is running with parameters:
‘/usr/NX/bin/nxexec –node –user lightdm –priority realtime –mode 0 –pid 12’
Can you tell us what is this process designated with –pid parameter – 12 in this case. We would need command line and environment for this process. Also can you confirm the operating system is in the login window state?
If not, it could be a cause for a problem as we are detecting that login window session is running here.
If there is no core dump for this case, please provide us with full logs
to forum[at]nomachine[dot]com. You can find instructions about debug and collecting logs here: https://www.nomachine.com/DT07M00098.
Thank you for cooperation in this matter. Can you please try attaching from the problematic machine to itself using nxplayer?
Please use the ‘NX’ protocol and ‘localhost’ as the host name in nxplayer application.
Please check if something changes in those circumstances and send us the logs from after this attempt as you did in your first post.
The first thing that comes to mind after seeing the logs is the problem with localhost entry in /etc/hosts file.
NoMachine uses localhost to connect locally via loopback device, so please make sure the localhost entry points to a loopback address, for example the line in /etc/hosts could look like this:
Please let us know if this does not help. If it doesn’t, more info about your network configuration would be useful, such as content of /etc/hosts/ and output of ifconfig.
There is nothing wrong with this logs itself, as they are part of the search for physical session. The problem here is probably the amount of sessions registered in systemd – which IDs are reaching 28760 here. Systemd has information there stored for every open session that goes through pam (physical desktop sessions, ssh sessions, nx sessions also). So as long as it is proper, this behavior is also proper. If the number of sessions is wrong, it may be indication of systemd problems, so please check if the number is right, as this information should be cleaned when the session closes.
For this log size I can propose two solutions.
First, you can disable offending function. If you do not need access to physical desktop on that machine, you can edit the “AvailableSessionTypes” key in server.cfg and remove “physical-desktop” item.
Second, you can pass server logs to syslog by uncommenting and enabling “EnableSyslogSupport” key in server.cfg:
and then enable autorotate in /etc/syslog.conf as you see fit.
Thank you for contacting us with this problem.
Unfortunately we can not determine where the problem is. To help us find it, we need more
information. Please follow this steps:
1. Shut down the NoMachine by running:
# /etc/NX/nxserver –shutdown
2. Ascertain there is no leftover NoMachine processes by running:
# ps -ef | grep nx
If not sure, please send us the list of processes.
3. Please gather the result of commands:
# ls -l /usr/NX/etc
# ls -la /usr/NX/var/db/running
4. Start the NoMachine by running:
# /etc/NX/nxserver –startup
5. If the problem repeats please attach to the nxserver –daemon process with strace program.
You can get the pid of valid process by running:
# ps -ef | grep nxserver | grep daemon
Please attach the results of this commands here.January 4, 2017 at 09:11 in reply to: Still cannot find default environment after TR09N07188 fix #13401
It seems that the problem lies in DefaultDesktopCommand key from node.cfg.
Please find this key in the /usr/NX/etc/node.cfg file. By default it should look like:
DefaultDesktopCommand “/usr/bin/dbus-launch –exit-with-session startkde”
You need to change the startkde to full path to this program eg:
DefaultDesktopCommand “/usr/bin/dbus-launch –exit-with-session /usr/bin/startkde”
If this does not help please edit the /usr/bin/startkde file by adding
line at the start.
Then please make sure that the SessionLogClean key in /usr/NX/etc/node.cfg
is uncommented and set to 0.
reproduce the problem and send us the logs again.December 15, 2016 at 08:46 in reply to: Still cannot find default environment after TR09N07188 fix #13189
It seems the server has trouble with finding working display. Can you give us
the output of:
# lsof -a -c Xorg -U
And if it gives any output, also:
# /bin/netstat -ln –protocol=unix
# ls /tmp/.X11-unix/
If the output include any sockets named like
please make sure that netstat has access rights on at least 755.
If not, there is a possibility that Xorg server has disabled listening on unix sockets, which are vital for connecting via NoMachine. Are you aware of any changes made in this regard? (any changes
in system configuration files, startx script etc.)December 5, 2016 at 10:29 in reply to: Still cannot find default environment after TR09N07188 fix #13082
First of all, it seems that there is something wrong with configuration files.
Can you please send us whole /usr/NX/var/log directory along with /usr/NX/etc/server.cfg
and /usr/NX/etc/node.cfg for investigation?
To fix it please try a clean installation – uninstall, remove the /usr/NX directory then install again.
If this does not help, please enable the logs as described here: https://www.nomachine.com/DT04M00076
then do /etc/NX/nxserver –restart as administrator and send us the /usr/NX/var/log directory.
Also it would help to debug the source of problem if you include the output of
ps awwxo uid,ppid,pid,sid,comm,args
when logged on to desktop.
Please send the logs to forum[at]nomachine[dot]com referencing the post topic in the mail title.November 10, 2016 at 09:44 in reply to: Frame buffer on server not started: nxFrameBuffer aborted #12856
It seems that the server has every session type disabled and this causes the connection problems. Please edit the server configuration file:
and make sure that key
is uncommented and it includes both nxvfb and physical-desktop entries.
For example working key for free version should look like this:
If modification is required, please restart nxserver (as administrator user)
and try connecting again.
If this does not help, please enable debug and submit logs.
Instructions are available here: https://www.nomachine.com/DT07M00098
Please include the configuration files:
Send them on to forum[at]nomachine[dot]com making sure to reference your topic.
The most probable cause for this problem is that Fedora 23 uses Wayland instead of X server. NoMachine is not yet compatible with Wayland, so disabling it is the only way to fix it.
By default Wayland is enabled on Login Window, to disable it for GDM, please edit
And under the tag
make sure the only line containing WaylandEnable field is:
Please let us know if it helps, or if the problem persists after disabling Wayland.
With logs provided, the problem is hard to debug, to handle it we would require
Please set in the node.cfg:
Also it seems, that master agent hangs in this case, so please add this line at the
bottom in the server.cfg:
This will cause the server to kill node with signal 11 instead of 9, so please make sure
the system can handle core dumps.
After this please restart the nomachine server:
Reproduce the problem and send the server and node logs as previously. We would also
require the full agent logs, so please include the full:
When the problem is reproduced, please do:
again so, if the Agent hanged, the system produce core report for nxnode process. We would
require the backtrace of all threads. The instruction is available here:
Also include the logs from client machine: .nx directory in user’s home.
In case of uncertainty please consult article on collecting logs:
Send all logs on to forum[at]nomachine[dot]com making sure to reference your topic in message title.
And some finishing questions: have you tried to log in as different user than root? Do the same problems happen?
Also is the machine you are trying to connect to on user desktop or Login Window?February 26, 2016 at 09:15 in reply to: Error Framebuffer on server not started: nxFrameBuffer aborted #10219
To analyze your problem further we need more information.
Can you enable debug and submit logs to forum[at]nomachine[dot]com? Instructions are available here: https://www.nomachine.com/DT07M00098
Also, do you have any desktop manager or Xserver configured on this machine or is it a headless Linux? If it is not headless, we would also require output of ‘ps -ef’ command or details about graphic environment configured there.
Please reference your forum topic when sending the logs.February 23, 2016 at 18:34 in reply to: 'No available sessions on this server' error for Ubuntu 14.04.4 #10189
It seems that the problem you have encountered most likely is caused by a corrupted nodes.db
During uninstall procedure we save the backup configuration files in /usr/NX/etc directory, so
reinstalling will preserve this problem. The safest option is to uninstall NoMachine, make sure
the /usr/NX/etc/nodes.db.backup file is removed, then install again.
You can also edit /usr/NX/etc/nodes.db.
The file should look like:
The problem will occur when first entry is different from “running”.