Mth

[Mth]

Hello.

The problem is with starting of nxclient –monitor process.
Unfortunately it is started as standard user and the logs will be saved in the home directory.

From the main logs the path in this case should be ‘C:\Users\Disaster\.nx\’

Just to be on the safe side please send us the whole ‘.nx’ directory to the same address.

/Mth

[Mth]

Hello

These errors should not be the cause of delay, they are from procedure that is started after the switch is detected.

Most likely right now there is no way to speed it up.

/Mth

[Mth]

Hello.

Yes the facts are pointing to the nxserver –daemon process that is responsible for physical session detection is somehow broken at machine startup.

There are no differences in how we check the running sessions, so the only thing that is different should be the context the nxserver –daemon is started with.

There is a faint possibility that during the Arch update and rollback that you mentioned the NoMachine service file was corrupted, did you perhaps try to reinstall NoMachine afterwards?

In any case we probably will need to investigate this further, could you provide more information about the OS setup that may be relevant? E.g. was there any custom pam.d modifications made? Is there any antivirus software running or any centralized user database like Active Directory configured? Or any unconventional services running on startup?

/Mth

[Mth]

Hello

So this looks fine. There are two possibilities either something is wrong with user ‘nx’ and access to the ‘ss’ command on login window,
or the problem is that nxserver process that runs it is started too early on the system startup and does not fully initialize.

Could you please run the following command like before – via ssh
when system is in login window:

sudo su nx -s /bin/bash -c '/bin/ss -lnx'

and see if there are any problems.

/Mth

[Mth]

Hello.

The logs indicate that nxnode process that is responsible for physical session is terminating with segfault. It is either system segfault or our abort procedure, we are not sure.

Please check the system logs for nxnode process with pid 11286. If there are any crash reports we would be grateful for a backtrace.

Also please include the rest of log files from our log directory besides the nxserver.log. We would require the nxerror.log and the node directory.

/Mth

[Mth]

Hello.

The logs are good, but a bit puzzling.

We are using installed external program ss to find the Xserver sockets that are running in the system to get which displays are to be made
accessible.

In your case the process “/bin/ss -lnx” returns nothing we can use. This is unusual, especially for Xorg. The process ends without error
so the number of options here are limited.

If you are able to connect to this machine via ssh when it is in the Login Window state, could you run the command:

/bin/ss -lnx

manually and confirm that there are not any failures or errors. If it is the case, we would need an output of three commands when machine is still in login
window:

/bin/ss -lnx
stat /tmp/.X11-unix/*
ps awwxo 'ppid,pid,sid,comm,args'

If there is a problem with sharing the output of ps program, we are only interested in the Xorg processes and their process tree (parents and children).

Please send the output of those commands the same way as previous logs.

/Mth

[Mth]

Hello.

First some questions.

1. You say it’s headless machine (without monitor) but there is gdm3/gnome installed. Does the desktop manager run and NoMachine connects to it, or does NoMachine create virtual session? If during connection you have a question asking to create desktop or if in server.cfg you have

CreateDisplay key uncommented and set to 1 – it is virtual one.

2. Is there any signs of nxnode/nxserver processes crashing in the system? By default there could
be a report in /var/crash directory. If that’s the case please provide us with backtrace, eg.

apport-retrace --output=nxnode.retraced /var/crash/_usr_NX_bin_nxnode.bin.1000.crash

Also please provide us with the content of /usr/NX/var/log directory from server machine.

Please send the logs to forum[at]nomachine[dot]com using the title of this forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello

The message:

Cannot detect any display running. Do you want NoMachine to create a new display and proceed to connect to the desktop?

Means that you do not connect to the physical session, but rather to the virtual session created by the NoMachine. It will most likely have default settings, so that is not a problem. The problem is that the NoMachine could not detect the running desktop session.

Unfortunately the logs You provided are not enough to see what is happening.

Currently there is an issue with new Wayland update where change to Xsockets prevent NoMachine from accessing it, so please check if that is the case and perhaps consider disabling it until the patched NoMachine version is released. If it is not Wayland issue please help us debug it by providing more detailed logs from the server machine.

Please follow the article on how to enable debug:

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

Then please do:

sudo /etc/NX/nxserver --restart

Gather the logs either manually or by executing:

sudo /etc/NX/nxserver --debug --collect

Please note this has to be done on the machine you are trying to connect to and send the logs to forum[at]nomachine[dot]com using the title of this forum’s thread
as the mail’s subject.

/Mth

[Mth]

Hello

The sudden appearance of the icon is caused by the delay in the local session finding. When there is no physical session, or when NoMachine cannot detect one we are disabling it for some increasingly longer time.

This is the problem here, that for unknown reason we cannot see the session either when it is on Login Window, or the problem appears earlier and is propagated.

If you are willing to help us debug this problem, we would probably require the logs for this.

Please follow the article on how to enable debug:

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

Then please do:

sudo /etc/NX/nxserver --restart

and reproduce the problem: most likely logout completly to Login Window, wait a few moments (around a minute would be best to be sure we run everything) and then login to the desktop.

Please send the logs to forum[at]nomachine[dot]com using the title of this forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello.

We currently are aware of a problem with Wayland on latest update. Since the problem seems to start on Login Window, could you confirm, the wayland is also disabled for the Login Window?

/Mth

[Mth]

Hello.

With how the session detection works right now it could be normal, unless there is a suspicion that something is hanging within the processes (both NoMachine or
lxde).

In theory when doing logout the Xserver for desktop should immediately shut down, which triggers the shut down of NoMachine agent. That should prompt new agent to be
launched for Login Window session. When the shut down of Xserver or agent is delayed though there could be a lag period.

Please check if there are any errors or warnings in /user/NX/var/log/nxserver.log file that could be pointing to an issue.

/Mth

 

[Mth]

Hello

There are not any known outstanding problems with access to Login Window on CentOS with gdm right now. The worst case would be if it was virtual machine and login window running on Wayland. In this case I would suggest disabling Wayland.

If there are no warnings/errors generated in the nxserver.log file this may be either something in the configuration or with the xserver.

The configuration thing to check would be:

sudo /etc/NX/nxserver --userlist

The entries there should show if any user has “Screen sharing” or “Access” disabled. If the user “gdm” has this disabled it may prevent anyone from seeing Login Window session.

If there is nothing helpful there, please gather logs and send them to us. Please follow the article on how to enable debug:

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

Then please do:

sudo /etc/NX/nxserver --restart

and reproduce the problem when user does not see the Login Window session. Please gather the logs either manually or by executing:

sudo /etc/NX/nxserver --debug --collect

Please send the logs to forum[at]nomachine[dot]com using the title of this forum’s thread as the mail’s subject.

Also what method are you using for logging out the inactive user? Any native method or some script?

/Mth

[Mth]

Hello

This is an ongoing issue for MacOS 10.15.16. There is a known problem on login window where the process responsible for grabbing session is started before the session is
properly initialized. Until there is a new version released it is a possibility to fixing this by logging via ssh and manually restarting the nxserver:

/etc/NX/nxserver --restart

If this does not help we would need to do some more debugging of this case.

/Mth

[Mth]

Hello.

First two questions:

1. Have you installed the new version from the desktop, or using command line? If from the desktop, has the user the administrator privileges?

2. After installation were you prompted with accessibility questions?

I am afraid this is something new that was introduced with the Catalina 10.15.6 update and has nothing to do with the accessibility any more, but we still need some data to
handle this.

Could you please follow this:

Please do:

sudo /etc/NX/nxserver --shutdown

Then navigate the OSX options to the “Security and Privacy”, the “Privacy” tab and from both “Accessibility” and “Screen recording” options please remove (by clicking ‘-‘ button, not just by disabling the checkbox) any and all “NoMachine”, “nxnode” or “nxserver” entries.

At this point for further investigation would be great to enable the logs in both server.cfg and node.cfg on the server machine. Please follow the article on how to enable debug:

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

Then please do:

sudo /etc/NX/nxserver --startup

and accept any requests for permissions from the operating system.

If the issue should persist after this, it would at least rule out any older bug being not fixed.
In this case please gather the logs either manually or by executing:

sudo /etc/NX/nxserver –debug –collect

Please send the logs to forum[at]nomachine[dot]com using the title of this forum’s thread as the mail’s subject.

/Mth

[Mth]

Hello

The error 108 with the context of the connection to physical desktop looks very strange. I’m afraid that we would require full logs to see what is going on here.

If you are willing to help us further please refer to an article on how to enable debug:

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

Enable debug on the server machine and then do:

sudo /etc/NX/nxserver --restart

And then please connect again to reproduce the problem. Then please gather logs either manually or by executing:

sudo /etc/NX/nxserver --debug --collect

Please send the logs to forum[at]nomachine[dot]com using the title of this forum’s thread as the mail’s subject.

And some question to clarify.

1. The error happens before entering the credentials, or after?
2. Are there any crash reports regarding nxnode or nxserver processes in the system. If yes, please send us the backtrace.
3. Is the machine in Login Window or desktop state. If on desktop, is there any screen saver/screen lock mechanisms enabled. Is Wayland enabled on both login window and desktop?

/Mth

[Author]

Posts