I notice that on a new CentOS image that I just booted up off of EC2 that the ulimit default is 1024 open files, but /proc/sys/fs/file-max is set at 761,408 and I'm wondering how these two limits work together. I'm guessing that ulimit -n is a per-user limit of number of file descriptors while /proc/sys/fs/file-max is system-wide? If that's the case, say I've logged in twice as the same user -- does each logged-in user have a 1024 limit on number of open files, or is it a limit of 1024 combined open files between each of those logged-in users?

And is there much performance impact to setting your max file descriptors to a very high number, if your system isn't ever opening very many files?

  • Added tags: bash linux kernel system-resources – Warner Mar 15 '10 at 16:56

file-max is the maximum File Descriptors (FD) enforced on a kernel level, which cannot be surpassed by all processes without increasing. The ulimit is enforced on a process level, which can be less than the file-max.

There is no performance impact risk by increasing file-max. Modern distributions have the maximum FD set pretty high, whereas in the past it required kernel recompilation and modification to increase past 1024. I wouldn't increase system-wide unless you have a technical need.

The per-process configuration often needs tuned for serving a particular daemon be it either a database or a Web server. If you remove the limit entirely, that daemon could potentially exhaust all available system resources; meaning you would be unable to fix the problem except by pressing the reset button or power cycling. Of course, either of those is likely to result in corruption of any open files.

  • Is my understanding correct, that the per-user limits set using ulimit are the same for all users? Is there a way to use different values per user or not? – Oliver May 15 '13 at 17:16
  • 1
    Yes, the settings can be set both globally and on a per user basis. – Warner Jul 17 '13 at 13:48
  • If i get your post right, this is not true. It is per process spawned by user xy, and this is limited by the filesystem maximum defined in /etc/sysctl.conf – Jeredepp Oct 9 '13 at 13:20
  • 3
    The ulimit limit is not per user, but per process! See unix.stackexchange.com/questions/55319/… – Læti Mar 28 '14 at 15:57
  • @Tonin - Yes, this answer is just wrong. – Nemo Feb 23 '15 at 19:38

The limitation of ulimit is per unique user. So user1, regardless of how many times logged in or processes running, would be limited to 1024. It's combined.

I am not sure if I completely understand the meaning of that sentence (English is not my mother tongue) If that sentence means the ulimit configuration for file descriptors is not a per-process limitation, the accepted answer (AFAIK) is wrong.

What I mean is, if some user has launched 4 processes and the ulimit configuration for FDs is 1024, each process may open 1024 FDs. The user is not going to be limited to 1024 FDs but the processes which are launched by that user.

For example:

me@superme:~$ ulimit -n
me@superme:~$ lsof | grep $USER | wc -l

Here a perl example where we reach the limit (it is a per-process limit):


$count = 0;

while ($count <= 1024) {
    $FILE = ${count};
    open $FILE, ">", "/tmp/example$count" or die "\n\n FDs: $count $!";
    push(@filedescriptors, $FILE);
    $count ++;


FDs: 1021 Too many open files at ./test.pl line 8.

1021 because there were 3 open file descriptors before reaching the while loop (stdout, stdin and stderr)

Sorry if I am completely wrong or I misunderstood the answer.

  • So, you are right. @Warner's response is wrong in this sense because the limit is on a per-process base and not per-user – filipenf Dec 2 '14 at 18:10
  • Just to mention: lsof reports not only File Descriptors, but opened files as well. Worth reading this article: thegeekdiary.com/… – ivanleoncz Apr 28 '20 at 23:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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