Another option would be to log a warning when process hits it's
filedescriptor limits.

I don't particularily like any further enhancements to /proc. /proc
is hack which should die painful death.

Jaromir

Jonathan Stone wrote:
> 
> In message <20020620220318.9B1057E04@beowulf.gw.com>Christos Zoulas writes
> >On Jun 20,  2:42pm, jonathan@DSG.Stanford.EDU (Jonathan Stone) wrote:
> >-- Subject: Re: Time to bump the default open files limit?
> >
> >What's wrong with checking EMFILE and ENFILE?
> 
> You need to have planned to check for it.  Our codebase (any of the
> *bsd's, for that matter) does not make that particularly easy.
> 
> Further, imagine you hit the limit on the shared file table.  How do
> you track which processes are currently hogging open files, or track
> the dynamic usage patterns over time?  In the end, I gave up and
> configured a kernel with MAXUSERS=2048, or something equally overconfigured.
> 
> Christos, I'm not asking for significant effort here. I'm just
> agreeing with Jason's experience: the ensuing errors aren't terribly
> obvious, and can be frustrating to track down.  I found very modest
> additions to tools /proc did help. But I dont know how that would
> affect other users (scripts, parsers, emul-compat issues...)
> of those tools.
> 


-- 
Jaromir Dolecek <jdolecek@NetBSD.org> http://www.NetBSD.org/Ports/i386/ps2.html
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-