Mth

[Mth]

Hello.

First let me elaborate on the available options.

When you have a headless Linux machine and NoMachine free version installed
and want to have access to graphic environment there are two ways to do it:

1. You can start it yourself by running the Xserver (like Xvfb) then starting
the environment (like “/etc/gdm/Xsession gnome-session”) there. This method
is explained in the article https://www.nomachine.com/AR10K00710.

2. You can let the NoMachine start its own Xserver on demand or by default.
If there is no Xserver running on the machine and the server.cfg key
DefaultDesktopCommand is set properly, during the first connection
you will be prompted to create and connect to new desktop.

That said, there are a few things to consider.

1. The physical desktop itself has to be installed. So like in the example
you provided (etc/gdm/Xsession gnome-session) both the Xsession script
and gnome-session have to be present.

2. When dealing with physical sessions, after changes in system it is good
practice to restart the nxserver afterwards. NoMachine regularly checks the availability of Xservers but when no Xserver is found after a certain time, it checks at longer intervals.

# /etc/NX/nxserver --restart

3. When starting Xserver by hand (like Xvfb in the topic you provided) you
have to make sure to start it as standard user and avoid starting it as ‘root’.
That is unless you specifically want to do it, starting graphical environment
as root can be dangerous. Here it is important to use the same user as the one
you want to use to connect via NoMachine. When the users are different, please
make sure that when on “no available sessions” screen the view is set to “All desktops” instead of “My desktops”.

And additional article that may help: https://www.nomachine.com/AR07Q01037

If there is nothing that helps in your problem, we could deduce more from the
NoMachine 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

[Mth]

Hello.

I am terribly sorry, don’t know where the error came from, but of course this
is MacOS, so the path is not /usr/NX, but /etc/NX.

So the commands should be:

‘# /etc/NX/bin/nxserver –userlist’

‘# /etc/NX/bin/nxserver –useredit –administrator yes’

Sorry for causing confusion.

/Mth

[Mth]

Hello.

Thank you for reporting the issue.

The first question is, when there was only one user in the system, was the operating system configured to log in this user automaticly,
or did you had to log in manually?

Second, do you have free version of NoMachine installed on the MacOS? If not, there could be two issues: one, when on “no sessions available”
screen, so please make sure the view is set to “All desktops”. The second is what account you are using: please make sure the user you are connecting with is marked as an administrator for NoMachine:

# /usr/NX/bin/nxserver --userlist

If it is not, please set it by running:

# /usr/NX/bin/nxserver --useredit --administrator yes

And try to connect again.

With the easy stuff ruled out, please gather logs for investigation.

Gather information from the MacOS system log, preferably by running:

# cat /var/log/system.log | grep -e nxserver -e nxnode -e nomachine >> system.debug

Also please collect NoMachine logs.

Article on how to collect logs:

https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

Please include the system.debug file and send them to forum[at]nomachine[dot]com using the title of
that forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello

From the logs you supplied it seems that the nxnode process that is accessing the physical desktop is segfaulting during the attach
procedure. This is causing the player to disconnect and trying to reconnect again, which with nxnode dead is causing a misleading
error “104: Connection reset by peer.”.

The nxnode process is dying with signal 11, so there should be a trace in the system logs or, if you have core dumps configured
a core file for investigation.

We are trying to reproduce this issue, but we would be grateful for a backtrace from this core file.

Please refer to the article https://www.nomachine.com/AR09L00810 on how to proceed with core file.

/Mth

[Mth]

Hello

The nxserver does a bit of monitoring in the background, NoMachine processes graphic environment tracking, which is not
always readily available in the system.

The 100% cpu usage after connection is unacceptable and abnormal though (unless of course there is a lot of swapping going on).

Could you please gather some logs for us to check this issue?

Article on how to collect logs:

https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

Please enable them, restart the nxservice:

‘# /etc/NX/nxserver –restart’

and then connect to the machine.

Also please include the strace for this nxserver.bin process.

‘# strace -f -p <nxserver.bin PID> &> strace.log’

You can find the nxserver.bin PID in the top view. Please let this command run for a full cycle of 100% usage and then terminate it with ctrl-c.

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

[Mth]

Hello.

This doubling of processes is most likely caused by the NoMachine starting the virtual desktop because it cannot detect the physical
desktop and the server.cfg key CreateDisplay is set to 1.

To avoid NoMachine creating it on each startup you can edit

/usr/NX/etc/server.cfg

config file and set this key to 0 or comment it.

This key may be set to 1 because when you first connected, NoMachine had no physical session detected, asked to create “Display on demand” (which is simple virtual session). When you select yes, there is a checkbox to select, which will make NoMachine to start this session automatically on startup.

Setting it to 0 will make it stop, but it does not solve the issue that you have running physical desktop and NoMachine did not detect it.

If this key is set to 0 and after doing

# /etc/NX/nxserver –restart

you would not get NX> 161 Enabled service: nxnode. and you cannot access your desktop, we would require logs
to investigate this further.

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

[Mth]

Hello

The good news is we were able to identify the problem, and the fix
is under way. The bad news is that we cannot provide a straightforward
workaround.

The problem is happening because of the strange dbus service behavior.
By the default dbus-daemon –session should be ran by the systemd
whenever the user is logged. Here it does not happen and instead it
is invoked during the start of the graphic environment by the gdm-x-session
process.

So we have three important processes running as gdm-x-session children:
Xorg, dbus-daemon –session and gnome-session-binary. Unfortunately
the dbus-daemon started like this lacks some of expected environment
variables, and the NoMachine fails the detection badly.

Please check if there is anything wrong with the dbus service for the user e.g. by
running

‘systemctl status dbus.service’

or checking if the file /usr/lib/systemd/user/dbus.service is present and viable.

If there is nothing wrong there, or it is not a result of an accident and this
behavior is intended, we may be able to provide with patched packages.

/Mth

[Mth]

Hello

There are a few things to consider here.
Is the spinning wheel happening on connection before NoMachine login
screen, after logging in, or is the connection established and then you see the
rotating icon?

Is anything happening on the problematic machine itself?

Usually, upon installation there should be a popup (if necessary) to handle access rights, maybe it was denied or revoked afterwards?

If we can’t establish that it’s a configuration issue, we would require 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.

We would need logs from the problematic target machine and nxplayer logs from the connection attempt (client side)

Also please check the system logs/journal for any errors/warnings or strange
entries considering loading of NoMachine services (localnxserver, nxserver, nxd).

/Mth

[Mth]

Hello

First, to answer the doubt about the Nvidia drivers, as long as there is
no problem on your side (everything is fine on physical screen), there
is no problem with them on our side. Right now as we see it from our logs
the problem is in between the Xorg display server and the NoMachine
ability to detect it.

We are still not fully sure on what causes this problem and trying to
find a solution that would fix this.

Could you please provide us with one more set of logs? This time please set
the server logs to verbose mode by editing the /usr/NX/etc/server.cfg file
and setting:

‘SessionLogLevel 9’

and then restarting the server.

‘/etc/NX/nxserver –restart’

After the restart please gather the logs as usual.

Please note that this would print much more details into the logs, so you would
want to turn it off afterwards.

Thank you for great cooperation and patience on this issue.

/Mth

[Mth]

Hello.

Glad to know you can now connect.

Can you explain what you mean when you write “it doesn’t show the authentication screen”? Are you talking about the Login Window screen, or administrator authorization when trying to access the directory? What exactly are you doing?

/Mth

[Mth]

Hello.

Even if it did not work, it gave some insight to the issue.

It seems something is interfering with the session detection mechanism. Always the same X server process is detected, regardless of the display parameter. This is the reason the proper session never gets detected. Because this is a relatively new version of Gnome, even if there is user desktop running already, there will be X server for login window.

Strange thing is, we haven’t been able to reproduce that issue, at least on standard configuration of Ubuntu 19.04. Please give us some information about your configuration.

1. Is it freshly installed Ubuntu 19.04, or updated from older version?
2. Do you have any changes in gnome configuration? It looks like there is no
Wayland running, but maybe that is the issue here that it is not detected.
3. Do You have any virtual X servers running? (like vnc or xvfb)
4. If You can, please provide us with output of

‘# ps -efjH’

command. As you wrote the desktop environment is Gnome, we are mostly interested in the process tree of “/usr/sbin/gdm3” process.

And of course any information about any changes in configuration of X server or desktop environment that is present on the system will be most helpful.

Also as the problem is related to the multiple X servers running, there could be a possible workaround, that is you can try to enable the automatic login for the user, and then restart the gdm service. This will cause the X server for login window to be skipped – at least at first, any logout/login afterwards would have it back.

You can then simply kill the “Xorg” process owned by the gdm user (with kill -TERM <pid>), as there is no real need for that second inactive session to be running in background at all time. It is a very weak workaround, but may be of some help.

/Mth

[Mth]

Hello

I am very sorry I got the configuration files mixed up.
The proper configuration is:

1. In /usr/NX/etc/node.cfg:

PhysicalDisplays :0-:1200

2. In /usr/NX/etc/server.cfg:

DisplayBase 1201

Also please note the lack of ‘:’ in DisplayBase. I’m really sorry about the confusion.

/Mth

[Mth]

Hello.

After analyzing the logs it seems that we have a problem with detecting physical session
on Ubuntu 19.04 that has eluded us until now. We will hopefully have it fixed soon.

In the meantime please try a workaround:

1. Please edit the server.cfg file located by default in ‘/usr/NX/etc/server.cfg’. Uncomment and edit
the key PhysicalDisplays, so it looks like:

PhysicalDisplays :0-:1200

2. Please edit the node.cfg file located by default in ‘/usr/NX/etc/node.cfg’. Uncomment and edit
the key DisplayBase, so it looks like:

DisplayBase :1201

3. Restart the nxserver service:

# /etc/NX/nxserver --restart

Please let us know if this worked for you.

/Mth

[Mth]

Hello.

While there is no indication in the logs why there was problem with the session at first,
the white screen is most likely caused by the Login Window screen on Wayland:

2019-08-30 14:43:41 832.519  1068 NXSERVER checkLocalSession: found X server process: [Xwayland        /usr/bin/Xwayland :1024 -rootless -terminate -accessx -core -listen 4 -listen 5 -displayfd 6]

Currently NoMachine does not work well with Wayland when using proprietary drivers,
or in virtual machines.

In the logs we noticed a standard Xorg server, which should work, but there is no connection attempt.

Please check if disabling Wayland on login window help in this case. Standard
procedure on Ubuntu is to edit /etc/gdm3/custom.conf file and uncomment or add line:

[daemon]
WaylandEnable=false

Please let us know if there are any more problems.

/Mth

[Mth]

Hello.

First thing, from the process list, the nxserver with parameters

–virtualsession –sessionid 13E01F5A403A80C32DFF113CDD094013

means that NoMachine could not find the physical session and is creating a virtual session for you to connect. So the question is, is the machine you are trying to connect to (RedHat) headless, or maybe the Xserver providing service is disabled?

If you can confirm there is a physical session running on that machine, there is a first problem – NoMachine was not able to detect the physical session.

Second problem is with that virtual session itself, as you mention the directory

F-C-slc14unw-1001-9838E2BA07BFF1EE5FF509D4F84AC661

is created, the information here is that the beginning letter F means this is failed session.

The most probable scenario here is that this session failed during the connection attempt, which produced the bizarre error that session does not exist.

The fact that the last process list does not have any nxserver –virtualsession
process running could mean the sessions are being created and rapidly failing.

Unfortunately to investigate this issue further, we would require 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.

Also please check the node.cfg configuration file, usually located on linux here:

/usr/NX/etc/node.cfg

and see if the config key DefaultDesktopCommand is set properly to the desktop environment
installed on the machine.

/Mth

[Author]

Posts