No Limits! We may all like no limits, but is it really such a good idea? Usually, when there are no limits, ‘there’ll be dragons’. It is the same with limits.conf, though for testing servers, a truly unlimited limits.conf helps!
What Is limits.conf?
The limits.conf file contains resource limit settings for the Linux operating system. When your Linux computer was installed, the file was created as part of the installation and contained values for resources like virtual memory size, the maximum number of files, and more.
These values are set to pre-specified limits to ensure that your Linux system will not easily overload. Otherwise, a rogue program or process could easily bring an otherwise performant system to a halt. Picture, for example, a situation where you set the maximum number of open files to unlimited, and a rogue process (being a process with a fault in it, or even a malicious piece of software like a virus or malware) now starts opening file after file on the system.
Soon the system will run out of a resource it needs to handle all these open files. Whether it be the processor in your system (the CPU), or memory or even disk in some cases, where for example, we may have configured the maximum core file size as unlimited, and we run large processes in a system with much memory and little free remaining space, or a small root drive.
In summary, using the limits.conf configuration file, a user (or sysadmin) can specify limits on resources available to the user and to the system.
The format of the limits.conf file (which resides in /etc/security/) is well defined. Generally, we will specify an applicable domain (like a user, a group, and even wildcards like *), a type (soft or hard limit), an item that the rule relates to (like the nofile item which defines the maximum number of open files, the locks item which defines the maximum number of file locks a user can hold, etc.) and finally a value (the actual setting/maximum).
The header of the limits.conf file clearly defines this in a suitable amount of detail:
If you would like to read more about each specific item and other configuration settings with the limits.conf file, simply execute:
At your terminal prompt.
Going Unlimited
In general, for all intents and purposes, one should never go unlimited with limits.conf. Then, you may ask, why this article? Well, whenever there is a rule, there is a valid exception. The exception, in this case, is for testing servers. When you do testing or Quality Assurance work of any kind, you will often run into the limits of a system.
Setting things up as unlimited, with a proper test/QA framework setup to take care of system resource management, is a valid exception to keeping reasonable and system-specific limits inside limits.conf. For all other servers, as indicated, a per-server configuration is preferred and recommended.
Without further ado, let us introduce a script which sets all variables and options in limits.conf to unlimited. This script is based on the GPLv2 licensed setup_server.sh script in the mariadb-qa repository on GitHub. You may also like to explore this script for other files you can adopt towards unlimited settings for a test server setup, for example /etc/sysctl.conf settings and /etc/systemd/logind.conf
To configure a server towards unlimited, execute the following script at the terminal prompt of the (test) server you want to configure as unlimited.
Warning: please note that doing this on a production machine is likely not a good idea unless you have a solid understanding of the change you are making, as explained in part in this article, and are making it for a specific and valid reason. Doing this change also has significant security implications, and it is recommended to do this only on a machine that is behind a firewall and VPN, i.e., not a public-facing server. TLDR; Proceeding to implement this is at your own risk.
You should also know that using a high number (greater than ~20000) for soft and hard nproc may cause system instability and hangs on Centos 7, though not on Ubuntu 18, 19, and 20. I, and other engineers with me, have used this setup for quite some time for testing servers, and for that application, it is ideal. Note how all of the settings are unlimited except nofile for which 1048576 is the maximum.
Once you executed this, simply restart your server to load all of the new configuration settings. You will not notice any difference, except that your test runs, if they were very resource-intensive, will not halt on various limit configuration issues anymore.
That said, as indicated above, you will need, as part of your testing framework, a solid watchdog and server resources monitoring process which ensures that your server does not become overused, which often results in hangs and reboot requirements. In a future article, I may provide the basics for such a script from where you can expand to cover your own setup.
Wrapping up
There are valid use cases for setting /etc/security/limits.conf to every possible maximum. They are generally rare (with testing servers being a notable exception).
In this article, we learned more about limits.conf: why it exists, and how to change its configuration. We explored the limits.conf format, syntax, and idioms and listed a simple script that can set all of our settings to unlimited.
Even if you want to configure your server to lesser limits, the script is easy to adapt and can be integrated (as GPLv2 code as described) into your own scripts: simply change unlimited to the desired values. This is also a straightforward way to quickly configure a server to the desired values and thus unify and code your server farm limits.conf setup.
Enjoy!
