From owner-freebsd-questions Mon Aug 4 00:04:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA18632 for questions-outgoing; Mon, 4 Aug 1997 00:04:50 -0700 (PDT) Received: from necropolis.org ([207.66.220.160]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA18605; Mon, 4 Aug 1997 00:04:41 -0700 (PDT) Received: from localhost (edmond@localhost) by necropolis.org (8.8.5/8.8.5) with SMTP id XAA02358; Sun, 3 Aug 1997 23:59:01 -0700 (PDT) X-Authentication-Warning: necropolis.org: edmond owned process doing -bs Date: Sun, 3 Aug 1997 23:58:59 -0700 (PDT) From: "Andrew N. Edmond" X-Sender: edmond@necropolis.org To: Terry Lambert cc: Cliff Addy , questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Too many open files in System! In-Reply-To: <199708032114.OAA02289@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk /* 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 . 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 ), 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 ::: \-/ :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::