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).
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.
These "default" limits are applied by:
init
orsystemd
process),fork(2)
time),systemd
, especially to the processes it manages,setrlimit(2)
).Normal users' processes cannot rise hard limits.
The Linux kernel
At boot time, Linux sets default limits to the
init
(orsystemd
) 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:
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
/etc/security/limits.conf
and/etc/security/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: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).
systemd
Nowadays,
systemd
is widely used, it replacesinit
and can also configure specific limits values, especially to the processes/daemons it manages and creates itself.Some limits it uses by default can be manually configured in
/etc/systemd/system.conf
. There is more information available in the documentation.On RHEL6 (CentOS6) "max user processes" is set to 1024 by default.
You can change this value in file:
See https://bugzilla.redhat.com/show_bug.cgi?id=432903 if you'd like to complain about it :)
Info on this is terrible on the internet, heres a limits.conf file i made for debian linux, showing all possible options and their maximum "safe" limits, tweak accordingly.
These are the highest values you can set, some things are hashed out, activating those causes you to error out and be unable to login to your console, modify the commented out options at your own risk, but you shouldnt need to (default is unlimited on most)
I hope this is usefull to someone, as i could not find this info anywhere, theres 4 hours of research on this file.
When you checked the limits, were you using the root user to do so?
From the
limits.conf
manpage:Using explicit usernames would resolve the issue in this case.
kernel/fork.c
On 64 bit Thread size is 8192
Now i get the total in kb in division by 4
Now i got the number of pages
The final result is
In this way you got the thread-max parameter and the default user process limit is half
ulimit from root
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.
Here * config will override whatever you set in previous config file. So ideally you configure your setting in this file.
It appears to be /etc/security/limits.conf
http://ss64.com/bash/limits.conf.html
I solved this after I struggled with this problem for more than an hour! I deleted the config and recreated the file like this:
After logout and login, limit was working: