Forum Replies Created
-
AuthorPosts
-
GegaParticipant
Hello ednaiul
The reason behind that is that all users write logs to those files.
We’re working on improvements to correctly manage files and eliminate all-writable files/directories from NX installation:
https://www.nomachine.com/FR11Q03892.It’ll be included in an upcoming release.
GegaParticipantAre you logged into system as user ‘root’? Seems like we do have problem in that case, but it’ll need investigation to find if/how that could be fixed.
GegaParticipantFull logs could shed some light on what’s going on, so please send logs to forum[at]nomachine[dot]com set specify troubles-with-enablelockscreen as Subject.
It’ll be good to know what are steps to reproduce this issue and how often that happens. I’d like to see also effective user of all nodes, and might be better to see all processes related to NX, so please send output of:
ps -ef | grep nx
along with logs.GegaParticipantHello,
1)Yes by default we match all cases, you can change that if you don’t want to match all cases. More details are listed in nxauth.conf file.
2)nxd.conf matches connections through NX protocol. So it’s purpose can be to restrict number of connections, by default we do that if there are more than 20 connections in last 5 seconds.
3)nxd jail’s purpose is to ban remote hosts that are making too much connections in a very little timeframe, so we set it to 5 seconds.GegaParticipantIt’s not clear why we aren’t able to lock with dbus, but problem here is this part: HOME=/var/NX/nx, nxnode is run as desktop owner so home directory should be desktop owner’s home directory, so HOME shouldn’t point to /var/NX/nx, Are you maybe using UserNXDirectoryPath? It could be related to problem described in this TR: https://www.nomachine.com/TR09Q09406
If that’s the case, then updating could help.
GegaParticipantHello ednaiul,
Logs might help to identify your issue, so please enable debug, than reproduce your problem, collect and send logs to us. This article shows how to collect logs: https://www.nomachine.com/DT10O00163
Please submit them to forum[at]nomachine[dot]com putting the title of your topic as the subject.
GegaParticipantCan you tell me exactly which NX version you’re using, and if you’re testing virtual session or physical? Are you sure that you know exactly when connection is dropped?
GegaParticipantHello lipigl,
The reason that session doesn’t change its status to disconnected, right away, is that agent waits for renewing of connection with a certain timeout. You can modify this timeout by uncommenting ProxyExtraOptions and adding timeout=<seconds> to this key located in node.cfg. e,g:
ProxyExtraOptions limit=256k,link=modem,timeout=5
Also there are number custom scripts that could be set in server.cfg/node.cfg and that are run at certain events, you could use those keys and custom scripts, instead of parsing nxserver –list output. Here are relevant keys:
UserScriptBeforeSessionClose
UserScriptAfterSessionClose
UserScriptBeforeSessionDisconnect
UserScriptAfterSessionDisconnect
UserScriptBeforeSessionFailure
UserScriptAfterSessionFailureYou can see more information about custom scripts in our documents:
If you use product with virtual desktops: https://www.nomachine.com/DT03O00126#11.4
If you use physical attach only: https://www.nomachine.com/DT02O00125#11.3GegaParticipantHello yinshslin,
Logs might help to identify your issue, so please enable debug, than restart nxserver:
nxserver --restart
run also:
nxserver --upnpstatus
and collect logs.
This article shows how to collect logs: https://www.nomachine.com/DT10O00163GegaParticipantProblem is caused by lack of resources, do you have enough RAM to run all that sessions? If yes please check also:
cat /proc/sys/kernel/threads-max
to see limit on the total number of processes on the system (threads)
To list also threads you need to add L switch to your ps command. e.g:
ps -efL | wc -l
Usually this problem comes out because of limits, specifically “number of processes” limit or “virtual memory” limit. You’ve shown us limits for common user, but as we’ve said before we’re more interested in limits of user “nx”, since it looks like that might be causing this issues. Let’s check limits set for nxserver daemon, since this process is run as user “nx”, to do that firstly run:
ps -ef | grep "nxserver.bin --daemon"
Then copy pid of daemon and run:
cat /proc/<pid>/limits
If you see that nproc or virtual memory limit are set, than you should set new limits in limits.conf.
nx soft nproc unlimited
nx hard nproc unlimited
nx hard as unlimited
nx soft as unlimited
GegaParticipantHello,
It looks like max user processes limit is reached for user nx, all nxserver processes are run with user “nx”. Your command shows limits for user root, so it doesn’t say much about limits for “nx” or any regular user.
For the nx user it’s advisable to set ‘unlimited’:
nx soft nproc unlimited
nx hard nproc unlimited
For more information please refer to: https://www.nomachine.com/AR04O00927
GegaParticipantHello,
This means that for some reason you’re not allowed to access physical display of current user. This can happen any of this
three reasons:1)LoginScreenAccess is set to 0 in server.cfg and system is in login window state.
2)You’ve changed settings by clicking on nxclient monitor menu and disabling “Accepting connections”, in this case nxclient monitor
icon will be grayed out.
3)PhysicalDesktopSharing from server.cfg is set to either 0 or 2 and connecting user has no permission to access physical display.GegaParticipantHello,
Firstly please try this:
1)Shut down nxserver:
/etc/NX/nxserver --shutdown
2)Clean nxerror.log:
> /Library/Application\ Support/NoMachine/var/log/nxerror.log
3)Start up nxserver:
/etc/NX/nxserver --startup
If nxerror.log still continues to grow, please collect logs and send it to us to investigate and provide proper fix. This article shows how to collect logs: https://www.nomachine.com/DT10O00163
As a workaround you could redirect all logs written in nxerror.log to null, to do that you need to:1)Shut down nxserver:
/etc/NX/nxserver --shutdown
2)Remove nxerror.log:
rm -rf /Library/Application\ Support/NoMachine/var/log/nxerror.log
3)Redirect nxerror.log to /dev/null:
cp -a /dev/null /Library/Application\ Support/NoMachine/var/log/nxerror.log
4)Start up nxserver:
/etc/NX/nxserver --startup
GegaParticipantFiles in /etc/NX/server/localhost/ are used internally and aren’t meant to be modified by user. It’s mainly used to indicate nx installation directory.
GegaParticipantFiles in /etc/NX/server/localhost/ are different, these are part of regular nomachine installation so there’s nothing to worry about.
-
AuthorPosts