Date: Sun, 3 Aug 1997 14:14:53 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: fbsdlist@federation.addy.com (Cliff Addy) Cc: edmond@shaman.lycaeum.org, questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Too many open files in System! Message-ID: <199708032114.OAA02289@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.95q.970803114414.5334B-100000@federation.addy.com> from "Cliff Addy" at Aug 3, 97 11:47:44 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > error on accept: Too many open files in system > > > > I set CHILD_MAX and OPEN_MAX to 4098 in the kernel, and I can't find a way > > to get accept to open any more sockets. Any ideas? > > This seems to be a FAQ (Frequently Asked Question). Unfortunately, it > seems to seems to also be a NAQ (Never Answered Question). I myself have > asked it several times and the answers, involving CHILD_MAX and OPEN_MAX > and limits, never work. Apparently, FreeBSD is too primitive to handle > more than a few files at once. > > (please realize the above is an intentional goad to get SOMEONE to finally > answer this. I love FreeBSD :) ) There are five limiting factors on the number of open files which a process can have: 1) There is a "soft" limit, which can be seen an raised with the csh "limit" command or the sh "ulimit" command. This is a soft quota. 2) There is a "hard soft" limit, which is set at login time and may be modified via the login.conf mechanism. This limit prevents you from raising the "soft" limit above a set maximum. 3) There is a "hard" limit, which is set at kernel compilation time, and limits the number of open files which may be placed in the per process open file table. 4) There is a "hard system" limit, which is set at kernel compilation time, and limits the number of files which may be placed in the system open file table and referred to by all process open file tables for all process simultaneously running on the system. 5) Available kernel memory for the file structures, vnodes, in core inodes, process open file table, and file buffers. It used to be that the only limits were 4 and 5. Unfortunately, a number of broken shells, like "bash", open all the files they can in order to get the last descriptor they can for use by the shell, so that shell scripts can be run without descriptor conflicts (the correct way for these shells to operate is to use a reference to a descriptor instead of a descriptor, and "dup2" the descriptor one higher each time a conflict arises; but these programs are written by students). AIX had similar problems, where "bash" (and other offenders) would open tens of thousands of files, until the per process open file table for the starting "bash" would consume all available kernel memory. Now there are quotas. #4 is about the only thing that can't be gotten rid of, once you get rid of "bash" and similar programs built-in "denial of service" attacks. It has to remain, so that it is possible to directly reference the system open file table from kmem to allow things like identd to operate (identd is needed for anal security configurations using firewall software that denies or allows on the basis of "user@host" rather than merely "host"). Identd doesn't work (or didn't work; it may have been repaired in a new release) on AIX because of this. For #5, you can always buy more RAM. To answer your question: you must increase all of these values, and if you are using select, #define FD_SETSIZE higher in your application before including <sys/types.h>. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708032114.OAA02289>