Too many open files

[John Esak]

I can't help much... But I can throw the 60 files out the door. That is not
any kind of limit on Linux... Even on the old...very old SCO's that was
quickly moved to 110.... The thing is that 60 is stuck in the filePro
errmesg file. You are seeing an overflow of some kind, but I doubt it is 60
files.  That's  just the only message there is to display. Updating the
error message files was always a slow going... Last thing to do kind of
thing. For a long time even with 110 file limit... The 60 would pop up now
and again. We finaly got it fixed on the SCO versions... But maybe this
Linux is rverted back to something older.

The actual limit was bypassed around 4.8.10.... With 4.8.10 still being
bad... Only 4.8.11 and higher had the problem fixed for good.  Only packages
later than that are not going to blow the files limit. 

Nancy, can you get to the point that shows the error.... Stop just before
that point and in the debugger ptint out all the open files with the F8 menu
that is inside the debugger.  Or was the F8 menu not in the 5.0 level
debugger?  If it si, you might see some that can be closed.  Although, as
you know, there is supposed to be no limit on number of open files because
of hanle management inside filePro.

John



> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com 
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
> m] On Behalf Of Fairlight
> Sent: Friday, October 01, 2010 5:37 PM
> To: filePro Mailing List
> Subject: Re: Too many open files
> 
> Simon--er, no...it was Brian K. White--said:
> > > *** A filePro Error Has Occurred ***
> > >
> > > File Table Full
> 
> That error is really ambiguous.  It doesn't determine if it's 
> hitting a
> filePro internal limitation, a user-wide limit, or a 
> system-wide limit.
> 
> However, the number 60 says it's internal to filePro, unless 
> some -really-
> insane administrator has been at your system internals.  The 
> defaults are
> huge on most systems...1024 minimum per user per login 
> session, and way
> more than that system-wide.  
> 
> The 60 is a number I've seen dating back to SCO systems.  I 
> believe this to
> be a filePro limitation.
> 
> > (for instance using a stock opensuse install I never set 
> anything having 
> > to do with open file limits and I never run into this, but 
> it's just 
> > because of the way opensuse happens to set it's defaults, 
> and certain 
> > accounting and quotas packages which I do not install. If I 
> ever did hit 
> > this problem, the way to fix it wouldn't be the same on a 
> centos or a 
> > debian box.)
> 
> System-wide limits are actually settable via a few special files under
> /proc, and I've done this before on other systems.
> 
> > 60 is a very small number so it sounds like a per process 
> or per user 
> > limit, because the system wide kernel limit is usually a 
> minimum of 8096 
> > and that is considered way too low, 65535, 131000 or 200000 
> are more 
> > sensible.
> > http://www.debianhelp.co.uk/kerneltuning.htm
> 
> I doubt it's the process or user limits.  I've not seen a 
> system with user
> process limits at 60 since 1990 on a BSD 4.3 Tahoe system on 
> a Unisys 7000,
> and that was specifically modified -to- keep users from 
> running away with
> the system.  Defaults in any modern distribution -should- be 
> much higher.
> 
> > All that said, the simplest and first thing to check is 
> ulimit. "ulimit 
> > -n" shows the max open files allowed for the current user. Run just 
> > "ulimit" as the user, and as filepro, and root. Do any of 
> those show any 
> > files limit or all unlimited?
> 
> Make sure you're using bash.  If you try it from any other 
> shell, it's not
> even present as a command.  At least not by default on 
> SLES10, it's not.
> 
> > How you would change these if they are too limited depends of the 
> > distribution. Probably there is some files in /etc that get 
> included in 
> > the users environment, or the overall servers startup 
> environment, and 
> > probably those files get edited by some 
> distribution-specific admin utility.
> 
> Or it's overrideable by setting files in /proc at the end of the boot
> process.  There are a bunch of ways to skin this cat--IF 
> that's the actual
> problem.  And I have severe reservations that the OS is to blame here.
> 
> What -I'd- really like to see is an `ls -l` of /proc/$PID/fd/* for any
> filePro process that's complaining about this.  My guess is 
> that there are
> a lot of opened files from lookups, imports, exports, whatever, that
> haven't been closed with the close command.  And that listing 
> would show
> you exactly which files are open yet.
> 
> mark->
> -- 
> Audio panton, cogito singularis.
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>