[ On Thursday, June 20, 2002 at 16:17:53 (-0700), Jonathan Stone wrote: ]
> Subject: Re: Time to bump the default open files limit? 
>
> 
> In message <20020620183733.A11267@noc.untraceable.net>Andrew Brown writes
> >c'mon...this is unix, dudes.  :)
> 
> ... And when your clever shell pipeline itself fails due to ENFILE?

Then you have far more serious problems on your hands (and hopefully
_lots_ more evidence of what's wrong).

> No reason to be quite so glib, if you haven't actually encountered the
> problem.  (I didnt recall fstat(1), but I did try similar hacks with
> lsof.  IIRC, failure due to hitting ENFILE, is exactly what I got.)
> 
> In Jason's scenario, if a daemon encouters EMFILE or ENFILE, even
> syslog(3) may fail, or syslogd could run into ENFILE problems of its
> own.  In which case there's no log message and (as Jason said)
> ENFILE/emfile is something you have to *think* to check for.

Jason's scenario was only EMFILE -- and Jason only (IIRC) suggested
bumping the per-process open files limit.  Jason's scenario was also
with a program that apparently had very bad error reporting.

Jason's suggestion really is not such a great idea though.

Bumping the default per-process 'nofiles' limit (OPEN_MAX) above 64 is
probably not a very good idea.  There may be a few systems where every
process, and especially unprivileged processes, might commonly need more
than 64 open files, and where the system has enough resources to allow
for such an increase, but in general this is a very rare situation and
bumping the limit can lead to all kinds of more nasty scenarios
(eg. where kern.maxfiles is hit).

ENFILE is a whole other issue.  IIRC there's a spew of kernel messages
to /dev/console when it's encountered (or there'd better be!).
Portmasters should 

If your system is running out of files you can apparently tune it with a
sysctl (kern.maxfiles), though as you say a system that's hit
kern.maxfiles should probably be rebooted just to be sure any daemons
that may have encountered ENFILE are refreshed and not left in some
error state (or dead).

BTW, you don't have to modify "maxusers" in order to get more system-
wide open file table entries by default.  It is currently set, by
default, with this preprocessor logic from param.c, so as you can see an
"options MAXFILES=9999" in your kernel config will override the default:

#ifndef MAXFILES
#define MAXFILES        (3 * (NPROC + MAXUSERS) + 80)
#endif

(Things like "options NRPOC", "options MAXFILES", and other normally
auto-tuned options should probably be described in options(4).)

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>