brotech

[brotech]

About the ‘there is problem with shared memory’ I need to explain better. It all depends on how Unix is dealing with MIT-SHM shared memory. We suspect an application is leaking shared memory. The operating system is not dealing with these memory leaks by its own. The available shared memory, in the end, is all taken and other applications, like NX, can’t allocate more. Why now? Well, can be some application upgrade… The solution is simple: find out which application is leaking shared memory and fix it. It’s unlikely that the application leaking shared memory is NX, since NX is in use on millions of machines and we had not similar reports from other users, but can be, of course, that’s why we need to investigate on your machine. We are also discussing the option of checking the shared memory in use, and recovering the segments that are clearly the fruit of some application’s leak. And! We have planned to move away from MIT-SHM, and use some shared memory interface that is more modern, multiple times… But the time is never enough.

[brotech]

Hello jnko,

sorry I made a typo, it should be ipcs -m instead of -s.

For question ‘why there is problem with shared memory’ – we suspect an application is leaking shared memory.

[brotech]

Hello jnko,

it seems that the white screen problem is related to shared memory.
Please share here output of commands:
ipcs -s

sysctl -a | grep shm

top -b -n 1

run through sudo or as root user.

regards

[brotech]

Hello jnko,

could you please send also NX/var/log/node directory from server side, and
.nx from nxplayer side ?

Regards

[brotech]

Hello StMartin81,

please enable logs for nxserver, nxnode and also nxwebplayer. You can do that using
one command:

sudo /etc/NX/nxserver –debug –enable all

Then restart nxserver(sudo /etc/NX/nxserver –restart), reproduce problem, collect logs
and please send again. In last logs there are only debug messages from server.

If the physical session is available, it will be on the list for administrators or trusted users only, until
FR mentioned by AMSCAE will be implemented and released.

[brotech]

Hello,

this is strange. So far we have not been able to reproduce it, so please enable debug, restart nxserver, reproduce the problem and then collect logs and send to us.

Detailed description is available here: https://www.nomachine.com/DT10O00163#1

Send to forum[at]nomachine[dot]com the TAR.GZ archive.

regards

[brotech]

Hello fermulator,

Sorry for the delay in replying, I thought we had already replied with the workaround.

The problem you experience might be related to your recent OS updates, in particular to krb5-workstation package.

We suspect that it’s:

https://www.nomachine.com/TR07P08710

The problem was solved in our test environment by downgrading krb5-workstation
package from:

Version     : 1.15.2
Release     : 9.fc27

to:

Version     : 1.15.2
Release     : 2.fc27

[brotech]

Hello,

could you describe the platform, architecture and package used to install NoMachine? We haven’t seen this problem in our lab, so having this additional information will help us to reproduce.

To speed up the investigation, please collect logs as described here:

https://www.nomachine.com/DT10O00163

Please send them to forum[at]nomachine[dot]com referring to your topic in the subject of the email mail.

[brotech]

Hello,

it appears to be the same issue. There is no temporary workaround unfortunately. Please sign up  to know when a fix has been released using the ‘notify me’ service.

Regards

[brotech]

Hello fun_9990,

We tested the same environment you have and reproduced a similar problem tracked here:
https://www.nomachine.com/TR03P08473

To confirm that it’s the same issue you reported, please check in your nxerror.log file
if a similar error is reported.

Regards

[brotech]

Hello,
we would also expect different results just after installing. There are not any additional steps required.

You used package i686 which is for 32bits platforms only. If your Centos system is 64bits
then please uninstall and download/install package with the x86_64 extension.

If this is not a case then something did go wrong and we need to take a look at the logs. So, please follow article:
https://www.nomachine.com/DT10O00163 and share with us logs by sending them to forum[at]nomachine[dot]com.

/b.

[brotech]

Dear jwgish,

thank you for logs. Unfortunately nxserver was not restarted, so these logs
don’t provide the necessary information to investigate the problem.

Please restart the server, you can do that from a console by running:

sudo /etc/NX/nxserver –restart

Then reproduce the problem (message: The server was unable to make the local display available or access to the local display is disabled.)

Collect and send us the new set of logs.

Additionally, please give us also the following information:

1) OSX version

2) Device type (e.g. Macbook Pro)

3) If a user is physically logged-in to the desktop or if there is the Login window.

4) If advanced configurations are set, e.g. LDAP etc…

Regards

[brotech]

Hello,
the server.cfg on OSX, which in your case is the client side, is not related to the issue which seems to happen on your Windows 10 – server side.

Please check the firewall, and network between those two hosts, and if everything is OK, then please
enable debug, collect logs on windows, and send to us. Please follow instructions from:
https://www.nomachine.com/DT07M00098

Regards

[brotech]

Hello Jeribo,
please enable debug, reproduce the problem and then send us the logs (to forum[at]nomachine[dot]com).
Please follow the instructions here: https://www.nomachine.com/DT07M00098
Regards

[brotech]

Hello redskate,
we are not able to reproduce such problem in our lab. Could you please enable debug restart
nxserver and send us logs if you can reproduce the issue ?

You can find instructions about debug and collecting logs here: https://www.nomachine.com/DT07M00098.

Regards

[Author]

Posts