Date: Fri, 27 Sep 1996 21:31:39 +0200 (MET DST) From: guido@gvr.win.tue.nl (Guido van Rooij) To: bde@zeta.org.au (Bruce Evans) Cc: hackers@FreeBSD.org, mark@quickweb.com Subject: Re: OPEN_MAX => which #define counts? Message-ID: <199609271931.VAA01983@gvr.win.tue.nl> In-Reply-To: <199609271024.UAA19546@godzilla.zeta.org.au> from Bruce Evans at "Sep 27, 96 08:24:34 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> No relation, except if OPEN_MAX is large (256 or so) and that many > files are opened by several processes, then you'll quickly run out of > system fd's. E.g., on a 16MB system, then defaults give kern.maxfiles = > 360, and kern.maxfilesperproc = 360. If OPEN_MAX or the soft rlimit > is set to 360, then one user process can eat all the system fd's, so > root won't be able to log in. This requires no special privileges. > This is broken as designed. It's easy to reduce the hard rlimit or > kern.maxfilesperproc so that a single process can't exhaust all fd's, > but the reasonable defaults of (CHILD_MAX = 40) and (OPEN_MAX = 64) > require an unreasonable number of system fd's (2560) to satisfy the > worst case. When I added maxfilesperproc, I made it default to maxfiles for backwards compatibilty. But indeed the reason for adding such a thing was to be able to at least have more control over how fd's can be spread out among processes. The same btw for maxproc and maxprocperuid. -Guido
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609271931.VAA01983>