Date: Sun, 3 Aug 1997 23:58:59 -0700 (PDT) From: "Andrew N. Edmond" <edmond@shaman.lycaeum.org> To: Terry Lambert <terry@lambert.org> Cc: Cliff Addy <fbsdlist@federation.addy.com>, questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Too many open files in System! Message-ID: <Pine.BSF.3.96.970803235437.1586B-100000@necropolis.org> In-Reply-To: <199708032114.OAA02289@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
/* text cut and pasted below */
> 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>.
Thanks for the great answer Terry, Cliff and ahem... Jordan :-)
In any case, the sysctl settings worked great, messed with login.conf some
as well, and the #define FD_SETSIZE works great.... except with...
mit-pthreads.
mit-pthreads is puking everytime I try to set the FD_SETSIZE (yes, before
<sys/types.h>), and even when I go into the pthreads source and try to
change that version of FD_SETSIZE, it's still puking at a value of 1024.
At 256 it works fine. Any ideas?
Andy
On Sun, 3 Aug 1997, Terry Lambert wrote:
> > > 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.
>
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
\-/ :::::::: Andrew N. Edmond - finger for PGP key :::::::::: \-/
/-\ :::::: ............ :::::: /-\
\-/ ::: edmond@lycaeum.org :::::: an1@anon.nymserver.com ::: \-/
/-\ : Director of the Lycaeum :: the Nymserver Administrator : /-\
\-/ ::: www.lycaeum.org :::::: www.nymserver.com ::: \-/
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970803235437.1586B-100000>