Take the 2-minute tour ×
Server Fault is a question and answer site for professional 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,

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)


EDIT -- SOLVED

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
3  
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
1  
You can post the answer as an actual answer after a certain waiting period. –  sysadmin1138 Feb 5 '12 at 12:49
1  
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? –  coincoin Aug 16 '12 at 15:14

5 Answers 5

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.

PAM

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/pam_limits.so.

This library will read its configuration from limits.conf and limits.d/*.conf, but even if those files are empty, pam_limits.so 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:

  case RLIMIT_NOFILE:
      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
    
@rogerdpack These files are used by PAM only. If PAM isn't involved, they are just ignored. This is already mentioned in my answer. Your comment is therefore redundant. –  Totor Sep 12 at 17:05
    
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 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 2 days ago

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

/etc/security/limits.d/90-nproc.conf

See https://bugzilla.redhat.com/show_bug.cgi?id=432903 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

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

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

http://ss64.com/bash/limits.conf.html

share|improve this answer
1  
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

kernel/fork.c

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))
 2017338

Now i got the number of pages

 echo $((8 * 8192 / 4096)
 16

The final result is

echo $((2017338/16))
126083

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
62932
echo $((62932*2))
125864 #we are near
share|improve this answer

Your Answer

 
discard

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.