Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have two CentOS 5 servers with nearly identical specs. When I login and do ulimit -u, on one machine I get unlimited, and on the other I get 77824.

When I run a cron like:

* * * * * ulimit -u > ulimit.txt

I get the same results (unlimited, 77824).

I am trying to determine where these are set so that I can alter them. They are not set in any of my profiles (.bashrc, /etc/profile, etc.). These wouldn't affect cron anyway) nor in /etc/security/limits.conf (which is empty).

I have scoured google and even gone so far as to do grep -Ir 77824 /, but nothing has turned up so far. I don't understand how these machines could have come preset with different limits.

I am actually wondering not for these machines, but for a different (CentOS 6) machine which has a limit of 1024, which is far too small. I need to run cron jobs with a higher limit and the only way I know how to set that is in the cron job itself. That's ok, but I'd rather set it system wide so it's not as hacky.

Thanks for any help. This seems like it should be easy (NOT).


Ok, I figured this out. It seems to be an issue either with CentOS 6 or perhaps my machine configuration. On the CentOS 5 configuration, I can set in /etc/security/limits.conf:

* - nproc unlimited

and that would effectively update the accounts and cron limits. However, this does not work in my CentOS 6 box. Instead, I must do:

myname1 - nproc unlimited
myname2 - nproc unlimited

And things work as expected. Maybe the UID specification works to, but the wildcard (*) definitely DOES NOT here. Oddly, wildcards DO work for the nofile limit.

I still would love to know where the default values are actually coming from, because by default, this file is empty and I couldn't see why I had different defaults for the two CentOS boxes, which had identical hardware and were from the same provider.

share|improve this question
Do you have anything in /etc/security/limits.d/ ? – Patrick Feb 5 '12 at 4:40
No, that dir is empty – nomercysir Feb 5 '12 at 5:02
You can post the answer as an actual answer after a certain waiting period. – sysadmin1138 Feb 5 '12 at 12:49
I once looked this up somewhere. The defaults are set by the kernel. Partly hard-coded, partly dependent on the available ram. I think I found that on Oracle Metalink in the context of setting up SLES10 for Oracle-DB 11.2 – Nils Feb 9 '12 at 21:55
Could this question be marked as solved? – user130370 Aug 16 '12 at 15:14

6 Answers 6

It appears to be /etc/security/limits.conf

share|improve this answer
I mentioned that in my post already. It has no effect, nor are those values (unlimited, 77824) set there for the respective machines (that file is empty). – nomercysir Feb 5 '12 at 4:36
oh i saw you checked the .bashrc etc. but didn't see you mentioned this one too. – Puddingfox Feb 5 '12 at 5:00

When you checked the limits, were you using the root user to do so?

From the limits.conf manpage:

NOTE: group and wildcard limits are not applied to the root user. To set a limit for the root user, this field must contain the literal username root.

Using explicit usernames would resolve the issue in this case.

share|improve this answer
Be careful, this is probably a Debian specific "feature". – Totor Mar 6 '13 at 15:54
Also, the limits.conf file is empty (as the limits.d directory). – Totor Mar 11 '13 at 2:02

On RHEL6 (CentOS6) "max user processes" is set to 1024 by default.
You can change this value in file:


See if you'd like to complain about it :)

share|improve this answer
I doubt this 1024 value for nproc is correct and the author said that its limits.d dir was empty, so the default value is obviously not defined there. – Totor Mar 11 '13 at 15:33
Totor can't argue with you technically but Tom I found it helpful so thanks! – Partly Cloudy Oct 11 '13 at 17:23

These "default" limits are applied by:

  • the Linux kernel at boot time (to the init process),
  • inheritance, from the parent process' limits (at fork(2) time),
  • PAM when the user session is opened (can replace kernel/inherited values),
  • the process itself (can replace PAM & kernel/inherited values, see setrlimit(2)).

Normal users' processes cannot rise hard limits.

The Linux kernel

At boot time, Linux sets default limits to the init process, which are then inherited by all the other (children) processes. To see these limits: cat /proc/1/limits.

For example, the kernel default for maximum number of file descriptors (ulimit -n) was 1024/1024 (soft, hard), and has been raised to 1024/4096 in Linux 2.6.39.

The default maximum number of processes you're talking about is limited to approximately:

Total RAM in kB / 128

for x86 architectures (at least), but distributions sometimes change default kernel values, so check your kernel source code for kernel/fork.c, fork_init(). The "number of processes" limit is called RLIMIT_NPROC there.


Usually, to ensure user authentication at login, PAM is used along with some modules (see /etc/pam.d/login).

On Debian, the PAM module responsible for setting limits is here : /lib/security/

This library will read its configuration from /etc/security/limits.conf and /etc/security/limits.d/*.conf, but even if those files are empty, might use hardcoded values that you can check within the source code.

For example, on Debian, the library has been patched so that by default, the maximum number of processes (nproc) is unlimited, and the maximum number of files (nofile) is 1024/1024:

      pl->limits[i].limit.rlim_cur = 1024;
      pl->limits[i].limit.rlim_max = 1024;

So, check your CentOS' PAM module source code (look for RLIMIT_NPROC).

However, please note that many processes will not go through PAM (usually, if they are not launched by a logged in user, like daemons and maybe cron jobs).

share|improve this answer
True, point taken, comment removed. I guess I would say that for most users, PAM is probably enabled, so I would recommend checking your /etc/security/limits.conf and /etc/security/limits.d/* files first. In this particular instance, which I also ran into, there is a 1024 process/total user threads limit imposed by default in CentOS 6 via a limits.d file. – rogerdpack Sep 12 '14 at 17:15
@rogerdpack yes, PAM is certainly enabled, but, again, as I said in my answer: "please note that many processes will not go through PAM (usually, if they are not launched by a logged in user, like daemons and maybe cron jobs)". Our discussion has no added-value, therefore, if you delete all your comments, I will delete mine. Thank you. – Totor Sep 15 '14 at 8:12


max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);

On 64 bit Thread size is 8192

 grep -i total /proc/meminfo 
 MemTotal:        8069352 kB

Now i get the total in kb in division by 4

 echo $((8069352/4))

Now i got the number of pages

 echo $((8 * 8192 / 4096)

The final result is

echo $((2017338/16))

In this way you got the thread-max parameter and the default user process limit is half

init_task.signal->rlim[RLIMIT_NPROC].rlim_cur = max_threads/2;
init_task.signal->rlim[RLIMIT_NPROC].rlim_max = max_threads/2;

ulimit from root

ulimit -u
echo $((62932*2))
125864 #we are near
share|improve this answer

There is one more possibility that the configuration for "noproc" is not working while configuring in /etc/security/limits.conf.

There is one more file which overrides your configuration /etc/security/limits.d/90-nproc.conf.

*          soft    nproc     1024
root       soft    nproc     unlimited

Here * config will override whatever you set in previous config file. So ideally you configure your setting in this file.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.