How to set ulimit in linux

View Discussion

Improve Article

Save Article

Like Article

View Discussion

Improve Article

Save Article

Like Article

ulimit is admin access required Linux shell command which is used to see, set, or limit the resource usage of the current user. It is used to return the number of open file descriptors for each process. It is also used to set restrictions on the resources used by a process.

Syntax:

To check the ulimit value use the following command:

Working with ulimit commands:

1. To display maximum users process or for showing maximum user process limit for the logged-in user.

2. For showing the maximum file size a user can have.

3. For showing maximum memory size for the current user.

4. For showing maximum memory size limit.

What are Soft limits and Hard limits in Linux? 

The soft limits are the limits which are allocated for actual processing of application or users while the Hard limits are nothing but an upper bound to the values of soft limits. Hence,  

Working with Hard and Soft limit values:

1. For displaying the Hard limit. Hard limits are a restriction to the maximum value of soft limits

2. For displaying Soft Limit. The soft limits are the limits that are there for processing.

3. To change Soft Limit values:

Note: Replace <value> with the value you want to set for the soft limit and also remember size can not exceed the Hard Limit!

4. Displaying current Values for opened files

Administering Unix servers can be a challenge, especially when the systems you manage are heavily used and performance problems reduce availability. Fortunately, you can put limits on certain resources to help ensure that the most important processes on your servers can keep running and competing processes don't consume far more resources than is good for the overall system. The ulimit command can keep disaster at bay, but you need to anticipate where limits will make sense and where they will cause problems.

It may not happen all that often, but a single user who starts too many processes can make a system unusable for everyone else. A fork bomb -- a denial of service attack in which a process continually replicates itself until available resources are depleted -- is a worst case of this. However, even friendly users can use more resources than is good for a system -- often without intending to. At the same time, legitimate processes can sometimes fail when they are run against limits that are designed for average users. In this case, you need to make sure that these processes get beefed up allocations of system resources that will allow them to run properly without making the same resources available for everyone.

To see the limits associate with your login, use the command ulimit -a. If you're using a regular user account, you will likely see something like this:

One thing you might notice right off the bat is that you can't create core dumps -- because your max core file size is 0. Yes, that means nothing, no data, no core dump. If a process that you are running aborts, no core file is going to be dropped into your home directory. As long as the core file size is set to zero, core dumps are not allowed. This makes sense for most users since they probably wouldn't do anything more with a core dump other than erase it, but if you need a core dump to debug problems you are running into with an application, you might want to set your core file size to unlimited -- and maybe you can.

If you are managing a server and want to turn on the ability to generate core dumps for all of your users -- perhaps they're developers are really need to be able to analyze these core dumps, you have to switch user to root and edit your /etc/security/limits.conf (Linux) or make changes in your /etc/system (Solaris) file.

If, on the other hand, you are managing a server and don't want any of your users able to generate core dumps regardless of how much they'd like to sink their teeth into one, you can set a limit of 0 in your limits.conf.

Another limit that is often enforced is one that limits the number of processes that an individual can run. The ulimit option used for this is -u. You can look at your limit as we did above with the ulimit -a command or show just the "nproc" limit with the command ulimit -u.

Once again, your users can change their limits with another ulimit command -- ulimit -u 100 -- unless, of course, they can't. If you have limited them to 50 processes in the limits.conf or system file, they will get an error like this when they try to increase their limits:

Limits can also be set up by group so that you can, say, give developers the ability to run more processes than managers. Lines like these in your limits.conf file would do that:

If you want to limit the number of open files, you just use a different setting.

Here we've given two groups and one individual increases in their open files limits. These all set hard limits. If you set soft limits as well, the users will get warnings when they reach the lower limit.

To see a list of the ulimit options, look at the man page (man ulimit). You will note that ulimit is a bash built-in -- at least on Linux -- and that the following options are available:

If you limits.conf file permits, you might see limits like these set up for particular applications that really need the extra capacity. In this example, the oracle user is being given the ability to run up to 16,384 processes and open 65,536 files. These lines would be set up in the oracle user's .bash_profile.

Setting limits can provide a defense against processes that go haywire and malicious processes that try to make your systems unusable. Just make sure that your limits work for you and not against you as you plan how your resources can best be allocated.

2-Minute Linux Tip: Learn how to use the ping command

Copyright © 2012 IDG Communications, Inc.