No limits! We may all like no limits, but is it really such a good idea? Usually, if there are no limits, “there will be dragons.” The same goes for limits.conf, but for server testing a truly unlimited limits.conf helps!
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 such as the size of the virtual memory, the maximum number of files, and more.
These values are set to pre-specified limits to ensure that your Linux system is not easily overloaded. Otherwise, a rogue program or process could easily bring an otherwise performing system to a halt. For example, imagine a situation where you set the maximum number of open files to unlimited, and a fraudulent process (being a process with an error in it, or even a malicious piece of software such as a virus or malware) now starts opening the file after file on the system.
Soon the system will run out of resource it needs to process all these open files. Be it the processor in your system (the CPU), or the memory or even the disk in some cases, where, for example, we have configured the maximum size of the core file as unlimited, and we are running large processes in a system with a lot of memory and little free space left, or a small root drive.
In summary, using the
limits.conf configuration file allows a user (or sysadmin) to specify limits on the resources available to the user and to the system.
The format of the
limits.conf file (located in
/etc/security/) is well defined. In general, we will specify an appropriate domain (such as a user, a group, and even wildcards such as
*), a type (soft or hard limit), an item affected by the rule (such as the
nofile item that defines the maximum number of open files, the
locks item defining 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 an appropriate amount of detail:
If you want to read more about each specific item and other configuration settings with the
limits.conf file, just run:
At your terminal prompt.
In general, one should never go unlimited in all respects
limits.conf. Then you might wonder why this article? Well, when there is a rule, there is a valid exception. The exception in this case is testing servers. When you perform testing or quality assurance work, you often run into the limits of a system.
Setting things up as unlimited, with a good test / QA framework setup to take care of system resource management, is a valid exception to keeping reasonable and system specific limits in place
limits.conf. For all other servers, as noted, a per-server configuration is preferred and recommended.
Without further ado, let’s introduce a script that contains all variables and options
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 want to explore this script for other files that you can use for unlimited settings such as a testing server configuration
/etc/sysctl.conf settings and
To configure a server to unlimited, run the following script at the terminal prompt of the (test) server you want to configure as unlimited.
Warning: Keep in mind that this is probably not a good idea to do this on a production machine unless you have a good understanding of the change you are making, as explained in part in this article, and need to do a specific and valid reason. Making this change also has significant security implications, and it is recommended that you only do this on a computer that is behind a firewall and VPN, not on a public server. TLDR; Implementing this is at your own risk.
You should also know that using a high number (over ~ 20000) for soft and hard nproc can cause system instability and hang on Centos 7, but not Ubuntu 18, 19, and 20. Me, and other engineers with me, have used this setup for quite some time for testing servers, and for that application it is ideal. Note that all settings are unlimited, except
nofile for which 1048576 is the maximum.
sudo bash -c "cat << EOF > /etc/security/limits.conf * soft core unlimited * hard core unlimited * soft data unlimited * hard data unlimited * soft fsize unlimited * hard fsize unlimited * soft memlock unlimited * hard memlock unlimited * soft nofile 1048576 * hard nofile 1048576 * soft rss unlimited * hard rss unlimited * soft stack unlimited * hard stack unlimited * soft cpu unlimited * hard cpu unlimited * soft nproc unlimited * hard nproc unlimited * soft as unlimited * hard as unlimited * soft maxlogins unlimited * hard maxlogins unlimited * soft maxsyslogins unlimited * hard maxsyslogins unlimited * soft locks unlimited * hard locks unlimited * soft sigpending unlimited * hard sigpending unlimited * soft msgqueue unlimited * hard msgqueue unlimited EOF"
Once you’ve done this, simply reboot your server to load all new configuration settings. You won’t notice any difference, except that if your test runs were very resource intensive, they won’t stop at various limit configuration issues.
That said, as noted above, as part of your testing framework, you need a solid watchdog and server resource monitoring process that ensures that your server is not overused, often resulting in crashes and reboots. In a future article, I can provide the basics for such a script, from where you can extend it to cover your own setup.
There are valid usage scenarios for the setup
/etc/security/limits.conf to every possible maximum. They are generally rare (with server testing being a notable exception).
We learned more about it in this article
limits.conf: why it exists and how to change its configuration. We got it
limits.conf format, syntax and idioms and a simple script listed that can set all our settings to unlimited.
Even if you want to configure your server at lower limits, the script is easily customizable and can be integrated (as GPLv2 code as described) into your own scripts: simply change
unlimited to the desired values. This is also an easy way to quickly configure a server to the desired values to unify and encrypt your server farm