How to set ulimit values
Environment
- Red Hat Enterprise Linux (RHEL)
Issue
- How to set
ulimit
values
Resolution
-
Settings in
/etc/security/limits.conf
take the following form:# vi /etc/security/limits.conf #<domain> <type> <item> <value> * - core <value> * - data <value> * - priority <value> * - fsize <value> * soft sigpending <value> eg:57344 * hard sigpending <value> eg:57444 * - memlock <value> * - nofile <value> eg:1024 * - msgqueue <value> eg:819200 * - locks <value> * soft core <value> * hard nofile <value> @<group> hard nproc <value> <user> soft nproc <value> %<group> hard nproc <value> <user> hard nproc <value> @<group> - maxlogins <value> <user> hard cpu <value> <user> soft cpu <value> <user> hard locks <value>
-
<domain>
can be:- a user name
- a group name, with
@group
syntax - the wildcard
*
, for default entry - the wildcard
%
, can be also used with%group
syntax, formaxlogin
limit
-
<type>
can have two values:soft
for enforcing the soft limitshard
for enforcing hard limits-
for enforcing soft as well as hard limits
-
<item>
can be one of the following:core
- limits the core file size (KB)data
- max data size (KB)fsize
- maximum filesize (KB)memlock
- max locked-in-memory address space (KB)nofile
- max number of open filesrss
- max resident set size (KB)stack
- max stack size (KB)cpu
- max CPU time (MIN)nproc
- max number of processes (see note below)as
- address space limit (KB)maxlogins
- max number of logins for this usermaxsyslogins
- max number of logins on the systempriority
- the priority to run user process withlocks
- max number of file locks the user can holdsigpending
- max number of pending signalsmsgqueue
- max memory used by POSIX message queues (bytes)nice
- max nice priority allowed to raise to values: [-20, 19]rtprio
- max realtime priority
-
-
Exit and re-login from the terminal for the change to take effect.
-
More details can be found from below command:
# man limits.conf
-
Note that the nproc setting can no longer be set in limits.conf. Please use
/etc/security/limits.d/90-nproc.conf
instead. Setting nproc in /etc/security/limits.conf has no effect in Red Hat Enterprise Linux.
Diagnostic Steps
-
To improve performance, we can safely set the limit of processes for the super-user root to be unlimited. Edit the
.bashrc
file and add the following line:# vi /root/.bashrc ulimit -u unlimited
-
Exit and re-login from the terminal for the change to take effect.
-
Can also run
ulimit -u unlimited
at the command prompt instead of adding it to the file/root/.bashrc
.
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
18 Comments
the example isn't helpful or referral to the man page wasn't either. Why don't you show them putting in the "oracle" user not the wildcard since that was the question.
This is just confusing!
Just give simple steps, not theory
ulimits are controlled in three places, as I understand it. The kernel, PAM, and your shell. You covered the shell part. You only half covered the PAM part: as well as the limits.conf file you have to make sure /etc/pam.d/login has a line that says "session required pam_limits.so". And this article doesn't cover the kernel part at all. You have to add a file in /etc/sysctl.d/ with "fs.file-max = 20000" (or whatever you want the number to be), then do "sysctl --system".
I agree. All steps need to be provided. This is an old article but there are things we don't have occasion to do, have never done, or have not done in a long time. I come here for those things and when the article is incomplete it doesn't help me as much as it could have.
I think command corresponding to ulimit should be listed here. This copy pate of limits.conf file
Hello, Values set by Ulimt command wont be persistent across reboot so it is always recommended to use the limits.conf. For example:
ulimit -l 128 ulimit -l128
After Reboot:
ulimit -l 64
A big piece that was missing is that a reboot is not necessary for the changes to the file to take place if you're concerned about a particular user or application. But if it affects root processes, you're most likely going to want to reboot.
Further, if it's a change for just an application or user, then all their processes must stop and they must login again, and the processes restart.
RHEL-7-specific version is here: https://access.redhat.com/solutions/1257953. I don't think RHEL7 should be mentionned in this article.
Thanks for the link, Ugo. I didn't know about the per-service overrides. But don't forget that the above stuff still applies in RHEL7 to the non-systemd parts of the operating system (like per-user limits).
if you set oracle maxsyslogins 2 , only 2 putty session allowed on Linux for any user. Likewise oracle maxlogins 2 , only 2 session able to open as oracle user. 3 session will get closed.
oracle hard nproc 10000
oracle soft nproc 10000
If It's too simple most people can't understand it.
It's not described what is meant by 'hard' and 'soft' here.
totally useless, doesn't work in RHEL 8.1. Please provide proper steps for RHEL 8.1!
The actual problem is that RHEL7 is implemented differently than RHEL6 and lower; and that is not called out in this article. Look here: https://access.redhat.com/solutions/33993
Actually this is only the content of the /etc/securty/limits.conf, and it is not useful.
Wouldn't setting nproc to unlimited undermine the very purpose of ulimits?.
"To improve performance, we can safely set the limit of processes for the super-user root to be unlimited. Edit the .bashrc file and add the following line:" - I am wondering how setting nproc to unlimited improve performance.
Agreed. This is not helpful. If I hadn't made it a habit to read the comments this would have left me wondering changes didn't work or take effect. This is also the top search item for relevance for RHEL 7. This is not the first time that this has happened doing searches for my company, causing me to have to open tickets.
If RedHat wants their Knowledge base to remain a relevant resource they need to review articles and update them appropriately.