65

I'm trying to install 389-ds, And it gives me this warning:

WARNING: There are only 1024 file descriptors (hard limit) available, which limit the number of simultaneous connections.

I understand about file descriptors, but I don't understand about soft and hard limits.

When I run cat /proc/sys/fs/file-max, I get back 590432. This should imply that I can open up to 590432 files (i.e. have up to 590432 file descriptors.

But when I run ulimit, it gives me different results:

$ ulimit
unlimited

$ ulimit -Hn    # Hard limit
4096

$ ulimit -Sn    # Soft limit
1024

But what are the hard / soft limit from ulimit, and how do they relate to the number stored at /proc/sys/fs/file-max?

d4nyll
  • 185
Rafael Adel
  • 1,281

2 Answers2

59

According to the kernel documentation, /proc/sys/fs/file-max is the maximum, total, global number of file handles the kernel will allocate before choking. This is the kernel's limit, not your current user's. So you can open 590432, provided you're alone on an idle system (single-user mode, no daemons running). File handles (struct file in the kernel) are different from file descriptors: multiple file descriptors can point to the same file handle, and file handles can also exist without an associated descriptor internally. No system-wide file descriptor limit is set; this can only be mandated per process.

Note that the documentation is out of date: the file has been /proc/sys/fs/file-max for a long time. Thanks to Martin Jambon for pointing this out.

The difference between soft and hard limits is answered here, on SE. You can raise or lower a soft limit as an ordinary user, provided you don't overstep the hard limit. You can also lower a hard limit (but you can't raise it again for that process). As the superuser, you can raise and lower both hard and soft limits. The dual limit scheme is used to enforce system policies, but also allow ordinary users to set temporary limits for themselves and later change them.

Note that if you try to lower a hard limit below the soft limit (and you're not the superuser), you'll get EINVAL back (Invalid Argument).

So, in your particular case, ulimit (which is the same as ulimit -Sf) says you don't have a soft limit on the size of files written by the shell and its subprocesses. (that's probably a good idea in most cases)

Your other invocation, ulimit -Hn reports on the -n limit (maximum number of open file descriptors), not the -f limit, which is why the soft limit seems higher than the hard limit. If you enter ulimit -Hf you'll also get unlimited.

Stephen Kitt
  • 434,908
Alexios
  • 19,157
  • please does the hard limit ulimit -Hn target the very limit of the system to allocated file descriptor capabilities ? – DiaJos Sep 19 '18 at 11:27
  • 2
    @Webman : no, it doesn't. ulimit only affects the limits for the current process.

    The limits of the current process are bequeathed to children processes too, but each process has a separate count. E.g. with ulimit -Hn 10, you can only have 10 file descriptors open at any one time. Each child process you create can only have up to 10 file descriptors too. Only the superuser may increase a limit once set. If you set one too low, your only option may be to kill your shell process and start a new one.

     – Alexios Sep 26 '18 at 06:55
3

The "select" system call is one of the many terrible brain dead design decisions of unix that makes even windows95 still look so good in comparison.

It should have been banned 20 years ago and then we might by now have ability to unlimited file handlers without problems.

You can increase the number of file descriptors easily with kernel configuration and ulimit BUT remember that if any library uses "select" system call your program will become instable and fail (unless the author knows and tests if the file descriptor number that is passed is larger than FD_SET_MAX and in this case switches to use poll or epoll in which case it is unclear why it was not written with this in mind from begin).

Select can only handle file descriptors from 0 to 1023 (or what else is set in the FD_SET hardcoded constant) and if you feed one with a higher value it will poke randomly in your memory and the select will never repeat the descriptor as working. Unfortunately many libraries still use select and you see it used in all over example codes and tutorials.

Terrible and the reason why this comment is a rant and an answer. Can't answer without getting angry.

Lothar
  • 154
  • 6
  • 19
    Your comment is a useful warning, but instead of taking a ranting tone, it would have been far more useful to have quoted the fd_set(3) man page and that the limit comes from FD_SETSIZE. And the best would have been a suggestion of a replacement call like poll(3), as in this answer – Davor Cubranic Nov 26 '19 at 19:48
  • this rant doesn't seem to have anything to do with the difference between the ulimit limits and file-max in /proc, nor do we know the software mentioned uses select() or is affected by its limitations. – ilkkachu May 13 '22 at 12:59
  • Yeah thats exactly the whole problem, we don't know the uses of select. Thats why it should never ever used, becuase it is the main limitation and the mother of all answers to the file descriptor question. – Lothar Jun 24 '22 at 18:24
  • 1
    Really enlightening, until reading this I would have used select as I was taught in college (~20 years ago). – user229044 Mar 27 '23 at 22:58
  • Dude. Lighten up. Raging against the machine is fine, but why rage against your grandmother's machine? The first paragraph of the select(2) man page says " All modern applications should instead use poll(2) or epoll(7)". – O. Jones Apr 23 '23 at 23:27
  • 1
    Thanks @O. Jones, but "nfortunately many libraries still use select and you see it used in all over example codes and tutorials" is still true. I guess it will be harder to bury "select" then it is to eliminate "gets" – Lothar Apr 25 '23 at 07:41