NoMachine Support

Your questions answered

Knowledge Base

Searching in: Articles & FAQs
Filter the search results
Applies to:
Last update:
Searching in: Articles & FAQs
ID: AR04O00927
Applies to: NoMachine Server
Added on: 2017-04-27
Last update: 2020-03-05
Troubleshooting issues caused by system resources exceeded on Linux

NoMachine server, as any other application, utilizes system resources to function properly.

If the available system resources are exceeded, users may be no longer able to create new virtual desktop, custom session etc... with NoMachine.

In this case it's necessary to increase resource limits. To change resource limits permanently and override the default system settings, administrators have to modify the /etc/security/limits.conf file and ensure that the system relies on this file. This file permits to set limits for all users or for specific users.

Error messages in console may show the cause of the problem.

Events related to exhaustion of system resources can be also found in NoMachine logs on client and server side. Collecting and reviewing them can be helpful to diagnose the problem (How to collect logs:



Check availability of system resources on the NoMachine server host

When it's no longer possible to create new NoMachine sessions, or performance becomes slow, it's suggested to inspect the available system resources and limits set on the Linux host where NoMachine server is installed. 

To do that, use the following commands:

top / htop   for tracking processes & their CPU consumption

free  for tracking available memory (unused and used RAM memory and swap space)

Although RAM memory is available, process limits can be exceeded:   

cat /proc/sys/kernel/threads-max   to see limit on the total number of processes on the system (threads)

ulimit -a   to see all current limits set for the logged user who runs the command

sudo grep -nr ERROR /usr/NX/var/log/   to find eventual errors reported in NoMachine logs


Note that the amount of RAM memory consumed by NoMachine is variable and depends on many factors (e.g. creating a custom session with a simple text editor will consume less resources than creating a virtual desktop with GNOME environment).
NoMachine performance is closely related to system as well as to hardware efficiency. Creating virtual and custom sessions implies the creation of new threads that, depending on the enviroment and on the application type, may require different amount of resources.
You may refer to the following article for some benchmark tests made on version 6:

Here we are presenting some of the most common cases of exhaustion of system resources and how to determine them.

1 - Too many processes running

NoMachine logs report:

14516 14516 14:01:57 571.575 Thread: ERROR! Thread creation failed.
14516 14516 14:01:57 571.786 Thread: ERROR! Error is 11 'Resource temporarily unavailable'.

To see the maximum number of processes available to a single user, run:

ulimit -u

To check how many processes a user has, run:

ps -L -u <username> | wc -l

At least one nxserver process is started for each session (two in case of reconnection to a virtual desktop or custom session). All of these nxserver processes  are running as user 'nx', please check the limits set for the user 'nx' as well. In case of large installation it's common to reach the 'maximum number of processes' for the nx user.

Note also that 'number of processes' is referring to threads, each 'nxserver --login' process has usually 12 threads.


2 - Too many open files 

NoMachine logs report:

2017-04-21 10:46:31 038.745 2622 NXNODE WARNING! Couldn't create pipe. Error is EMFILE, Too many open files

2017-04-21 10:46:31 038.788 2622 NXNODE ERROR! Cannot create mono pipe for child stdout.

2017-04-21 10:46:31 038.826 2622 NXNODE ERROR! Error is: 24, Too many open files.

To check how many open files a user has, run:

lsof -Fn -u <username>| sort | uniq | wc -l

(on some OS it is: /usr/sbin/lsof -Fn -u <username>| sort | uniq | wc -l )

To see the per-user limit of maximum open file descriptors, run:
ulimit -n

Note for systems using Systemd

Depending on Systemd configuration, it's possible that limits set in /etc/security/limits.conf are ignored.

In this case even when ulimit is set, the user's limit of maximum open file descriptors in the NoMachine session is still different.

For example if the /etc/security/limits.conf file has set:

   <username>  -    nofile          800108
   nx                  -    nofile          800108
   nxhtd             -    nofile          800108
the user still has open files limit 1024 as set in systemd configuration.

Systemd limits are set in the following files:

We recommend to refer to the official documentation of systemd for your OS to change settings.


If instead of error 24 NoMachine logs report:

2020-01-20 10:28:05 079.983 97449 NXSERVER WARNING! Error is: 23, 'Too many open files in system'.

it means that the maximum number of open files is reached globally.

To check how many files is open in the system, execute:

lsof -Fn | sort | uniq | wc -l

To check the global limit of open files run:

cat /proc/sys/fs/file-max


sysctl fs.file-max

To modify the value in current session, run:

sysctl -w fs.file-max=(new_value)

To make the change persistent after reboot add following line in /etc/sysctl.conf file:



3 - Exhaustion of virtual memory resources

NoMachine logs report:

2903 2945 12:40:16 895.512 Thread: ERROR! Thread creation failed.

2903 2945 12:40:16 895.874 Thread: ERROR! Error is 11 'Resource temporarily unavailable'.

2903 2945 12:40:16 896.019 Scheduler/Scheduler: ERROR! Failed to create the slave thread.

Error: Failed to create the slave thread.

To see the maximum amount of virtual memory available to the process, use:
ulimit -v

How to increase system resource limits

If you’re a system administrator you may want to change limits set to specific values depending on your needs. To set limits permanently, it's possible to add system-wide rules or rules for specific users and groups of users. These rules are set in the system configuration file, /etc/security/limits.conf. Please refer to the official documentation of your Linux distribution for detailed instructions.

Note that it's necessary to increase both hard limits and soft limits, when applicable.

Some examples of rules set in the /etc/security/limits.conf for a specific user are below.

a) Maximum number of processes

<username> hard nproc <number>
<username> soft nproc <number>

For example:
nxtest01 hard nproc 16384
nxtest01 soft nproc 16384

For the nx user it's advisable to set 'unlimited':
nx soft nproc unlimited
nx hard nproc unlimited

b) Maximum number of open files

<username> hard nofile <number>
<username> soft nofile <number>

For example:
nxtest01 hard nofile 63536
nxtest01 soft nofile 63536

'nofile' limit cannot be higher than value defined in /proc/sys/fs/file-max.

c) Maximum virtual memory (KB)

<username> hard as <number>
<username> soft as <number>

For example, to limit RAM usage to 4G for user nxtest01:
nxtest01 hard as 4000000
nxtest01 soft as 4000000

or to make it unlimited:
nxtest01 hard as unlimited
nxtest01 soft as unlimited

d) Maximum stack size (KB)

<username>  hard stack <number>
<username>  soft stack <number>

For example:
nxtest01 hard stack 8192
nxtest01 soft stack 8192