Forum Replies Created
-
Posts
-
Hello.
Thank you for the logs.
It seems that, while not on user desktop which uses Xorg, the gdm login manager is using Wayland. Unfortunately our video grabbing method for Wayland does not work on virtual machines yet.
Right now the only way for NoMachine to work properly is to disable Wayland on login window screen. For Ubuntu and gdm this would be editi
ng/etc/gdm3/custom.conffile and adding oruncommenting the line:
WaylandEnable=false/Mth
Hello.
There could be a few things that can be at fault here.
1. Is the remote machine headless? Are you connecting to actual physical session?
If there is a problem with detecting physical session, the NoMachine will create a virtual one
to connect, and logging out would cause the session to shut down.2. If there is actual physical session, please check if the Login Window is running Xserver
or Wayland. If it is Wayland, please try to disable it and see if that helps.3. There is a rare case when Login Window is wrongly identified as running as different user.
Please check if after connecting to the server the view is set on “All desktops” instead of
“My desktops”If this does not help, please provide us with logs.
Article on how to collect logs:
https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)
After gathering logs, please send them to forum[at]nomachine[dot]com using the title of that forum’s
thread as the mail’s subject./Mth
Hello.
next startup choosing YES, as soon after it closes it, it restarts the NoMachine program on the same Windows session without restarting the Windows.
This is indeed not the expected behavior. Could you provide more information?
Please tell us if it is a fresh installation or an update from an older version?
Is anything in the system logs concerning nxservice system service?We will probably need to see the logs to know why is it happening. Please collect
logs from server (whole log directory) and client –monitor. This would be points 2.3 and 1.4 from article.
I don’t know if it can be reproduced, but just in case, please try doing everything from point 1.4
(steps 1-5)Article on how to collect logs:
https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)
After gathering logs, please send them to forum[at]nomachine[dot]com using the title of that forum’s
thread as the mail’s subject./Mth
Hello.
Thank you for the logs.
It seems you have encountered a bug in the cleaning old connection procedure. We are investigating it further.
Unfortunately right now the only way to fix it would be to restart the NoMachine service by running:
# /etc/NX/nxserver --restart/Mth
Hello
Thank you for the logs.
It seems the NoMachine is not running at all, please try to run:/Applications/NoMachine.app/Contents/Frameworks/bin/nxserver –restart
and check the output of that command. If it still does not work after this
enable the NoMachine logs as described in this article:https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)
and repeat the nxserver –restart command and then send us those logs. You can attach them here or send to forum[at]nomachine[dot]com making sure to include the title of your topic in the subject.
/Mth
EDIT: Topic closed, assuming that the user did a restart as suggested and that solved the issue.
Hello.
This new information provided good insight into what is going on.
When you get the message:
Cannot detect any display running. Do you want NoMachine to create a new display and proceed to connect to the desktop?
In the player, this means that for some reason the local (physical) session detection mechanism failed,
and NoMachine could not make the session available.Selecting ‘yes’ as the answer to this question would make the server create a virtual session
to work on. So the behavior was different, because you were never connecting to the physical
session, which would have to include the Login window screen.So to the problem itself is why NoMachine failed to detect the session. There can be a few options here:
1. The Xserver started after the nxserver started during the system startup, and you have connected before the detection could have been completed. Then, since you selected “yes” as mentioned earlier and created the virtual desktop, you can now only get the access to this virtual session.
So the first thing to try is to check the /usr/NX/etc/server.cfg file and make sure that ‘CreateDisplay’ key is commented or set to 0. And then run:
# /usr/NX/bin/nxserver –restart
and see if the physical session was detected and made available. Please remember the virtual session will be lost when restarting the nxserver, so saving any work or keeping unfinished processes until they finish is advised.
2. After operating system restart, the Xserver providing service is disabled.
If you have physical access to this machine and/or can confirm the Xserver is running, please do so. With only console access the easiest method is to search process tree for X/Xorg processes:
# ps -ef | grep X
or for wayland processess
# ps -ef | grep ayland
If there is nothing running, you will have to re-enable the service from the console, and then restart the nxserver.
3. If the Login Window is running on Wayland, please try to disable it, so the simple Xserver is used, then restart the nxserver and try to connect again.
4. If everything fails, the cause is with the session detection procedure, and to help further, we would require the logs from the nxserver startup.
Please refer to this article on how to collect logs:
https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)
And please run:
# /usr/NX/bin/nxserver –restart
after enabling logs, so the detection procedure made on startup is logged.
After gathering logs, please send them to forum[at]nomachine[dot]com using the title of that forum’s
thread as the mail’s subject./Mth
Hello
This looks like a known bug described in:
https://www.nomachine.com/TR04Q09228
It will be fixed in the upcoming release.
In the meantime you can disable Wayland as an workaround to keep the connection to your local session available as suggested in the same report.
/Mth
Hello.
There is one more possibility to check.
When connecting to the server, are you using any kind of services through player like disk or printer sharing or file transfer?If you are, please check if one of those is not causing the connection problem by disabling them, or if there is any correlation between using them and disconnection.
If this fails, I’m afraid the only thing that is left to consider is a connection problem. Here are two points:
– If you have dynamic IP address, please check if the renewal is not happening at the time of disconnection.
– The connection address is within the Oracle dynamic DNS service address pool. This is another potential weak spot for the connection.
/Mth
Hello
The logs from the server are suggesting the problem may be either with the player or with the internet connection itself, as our agent reports no data from the player for an extended time (over 1 minute) without the connection actually breaking.
Can you explain what are you experiencing on client side when you are “kicked off”? Is it straightforward termination of connection without error, and going back to “recent connections” screen? Or there is “spinning wheel” screen between?
Please also provide us with the client application logs as explained in the point 2 of the article:
https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)
Please note that if there isn’t any error in the player application, you will have to disable log cleaning and reproduce the problem again.
Please send us the logs as previously.
Also as there may be indication of unstable connection, please make sure there is no problem in the system logs on both machines (with the logs more suggesting the problem is on the client side).Common problems may be caused e.g. by router IP lease time configuration or ISP interfering with some ports usage.
/Mth
Glad to be of help.
Just to be exhaustive as possible, there is an additional key in the server.cfg file: DisplayOwner.
If there is only one user that will be logging into the machine or that would need
to have the desktop environment running, it could be specified here, so the
desktop is always created on nxserver service startup, eg:CreateDisplay 1
DisplayOwner “test”providing that there is no native Xserver running would cause on nxserver service
startup to start an virtual desktop for user test.If there is a need for different users to be able to create this desktop on demand, I would
recommend to have CreateDisplay value set to 0.Also for starting terminal session for one user and switching to another by ‘su – username’,
I would really not recommend it, as the NoMachine agent that provides the Xserver
would work as different user, and there is no guarantee that some of the features
that requires user permissions won’t fail./mth
Hello.
If you are getting warning:
NX> 162 WARNING: Cannot find X servers running on this machine.
It means the desktop environment you installed there is probably not started during container startup.
This means the NoMachine free version can start its own virtual Xserver with desktop environment running. It seems to be happening here, that’s why there is no desktop manager window.
Why the desktop is running as root – there could be two reasons for this.
First, you could be logging in by the nxplayer using root account, then choosing to create desktop on demand when asked by the player.
Second, nxserver could be configured to run the root desktop automaticaly on startup.
This could happen, if first login via nxplayer you ever made was using root account and during this you chose “yes” to create desktop on demand query and then chose to create it automatically.Please check the server.cfg file (by default located in /usr/NX/etc directory) in the container and see if the key CreateDisplay is commented or set to 0.
If it is set to 1, please set it to 0 and do /etc/NX/nxserver –restart, then try to connect using NoMachine player and log in as normal user.
This should allow you to start desktop environment as that user.
/mth
Hello.
From what I understand here, the problem is with NoMachine creating a virtual desktop on the machine that should have its own Xserver running, but since it is after operating system restart, the Xserver may be starting after the nxserver.service, so your first connection is either before the running Xserver detection, or the nxserver configuration is set to start the virtual desktop automatically.
Please check the server.cfg file for CreateDisplay key and make sure it is commented or set to 0.
This will ensure that NoMachine will not create the virtual session automatically in the case Xserver is not available at the time of startup.
After this change the only way the virtual session could be created is when attaching to the machine
while the Xserver is unavailable. Then there will be a prompt in the player application to make a choice of creating one or not.Please also note that if the Xserver is not running at the time of nxserver service startup, there would be a growing delay for the check if one is actually running, so if the Xserver is started a few minutes after the nxserver service it may be recommended to restart the nxserver.service to make the check immediately.
/mth
Hello
From the logs and the symptoms it seems that there is a problem with the “/usr/NX/var/log/nxerror.log” file access as every nxnode process reports:
2019-03-21 16:56:30 288.624 1376 NXSERVER Parse local node message ‘NX> 596 Error: Cannot open /usr/NX/var/log/nxerror.log – ‘Permission denied’.\n’ on FD#14.
and then closes.
This matches with file access rights from the log directory you provided. It seems that two of our log files nxerror.log and nxd.log have wrong access rights 600. Please ascertain if it is the same on your machine.
Proper access rights to those files should be:
stat /usr/NX/var/log/nxd.log
Access: (0644/-rw-r–r–) Uid: ( 123/ nx) Gid: ( 0/ root)stat /usr/NX/var/log/nxerror.log
Access: (0662/-rw-rw–w-) Uid: ( 123/ nx) Gid: ( 0/ root)So here in this case running
# chmod 644 /usr/NX/var/log/nxd.log
# chmod 662 /usr/NX/var/log/nxerror.logAnd then restarting the nxserver:
# /etc/NX/nxserver –restart
Should fix the issue.
/Mth
Hello
Please check the following workaround for this problem:
Edit the:
/usr/dt/config/Xconfig
configuration file on the Solaris system so the Dtlogin*grabServer field
is set to False and is uncommented:Dtlogin*grabServer: False
then restart the cde-login service for example by running:
# svcadm restart cde-login
Then try XDM session again.
/Mth