"no file" message--summary of responses

[Robert Perlberg]

Dear Wizards and Wizettes,

I have received many responses to my request re: what the "no file"
message means.  They all basically said:

>It means that they system has run out of slots that it can open files with.
>
>
>There is probably some process opening LOTS of files.
>	andy

If this sort of thing happens again, I will try to find out if this is
the case.

Thanks to the following people for mailing me responses:

<philabs!ihnp4!ihlpg!timborn>
<philabs!linus!decvax!bellcore!mhuxr!mhuxt!houxm!whuxl!whuxlm!whuxcc!crash>
<philabs!linus!decvax!cwruecmp!ncoast!allbery>
<philabs!seismo!zehntel!zinfandel!berry>
Andrew Scott Beals <ihnp4!lll-crg!bandy>
Jack Jansen <ihnp4!seismo!mcvax!jack>
Tovar <ihnp4!seismo!SU-AI.ARPA!TVR%CCRMA>
philabs!musocs!mcgill-vision!mouse (der Mouse)
sdcrdcf!sdcc3!sdcc3:jack!man!ncr-sd!ncrcae!sauron!wescott

Here is a sampling of the other responses which represents the
information I received:

Bob--
	The DEC error reference manual says that "no file" means that
the system file access control table has overflowed, eg, a new reference
to a file has failed.  It goes on to state that if this condition
persists, increase the number of entries currently allocated for the
systems open-file table (files in ../dfile) in your system desc. file
and gen a new system.  Since pipes are files, once this table overflows,
no more pipes.  However, I think this message also comes up when a
filesystem "disappears" from the mount table, meaning that the disk
has gone offline.

	I hope this helps out.  I should note that this applies to
System V, I have no real knowledge of the Berkeley error messages.


			Jim Webb
			ATT BELL LABS
			ihnp4!opus!jrw



+---------------
I just fixed this on a Plexus P/60 recently.  The message is from the kernel
(in our case, /sys3) and means that the file table is full.  On V7, Xenix, and
System III (I don't know enough about sys5 or 4.2BSD to say whether this is
safe) a quick fix is to adb -w /sys3 (or /unix or /xenix or /vmunix or ...)
and patch the _v structure at the offset for v_nfile (see <sys/var.h>).  It
should be a long.  Just add some number to it; in the three OSes I mentioned
above, there are no dependencies requiring other parameter changes, and you
don't have to relink the kernel to make it useable.  After this, reboot and
you'll have a larger file table.  (If you're wondering, we got the message
when we had 11 people on the P/60, 10 in RM/COBOL and 4 in Informix-SQL (all
4 shelled out of SQL to get into RM/COBOL).)

--Brandon
-- 
	From the Heart of the Golden Apple...

..decvax!cwruecmp!ncoast!tdi2!brandon (cwruecmp is Case.CSNET, O ye Arpanauts)
(..ncoast!tdi2!root for business)     6615 Center St. #A1-105, Mentor, OH 44060
Phone: +01 216 974 9210      CIS 74106,1032       MCI MAIL BALLBERY (part-time)



os/fio.c has a message "no file structures" that comes up when it cannot
allocate a struct for file creation.  I'm not sure if this is what you are
after on not.

tim born
...ihnp4!ihlpg!timborn


Robert,

	Grepped the source as you suggested.  Your problem might
be a file table overflow.  When there are no available file structures the
message, "file table overflow" is printf'd to the console.  We're running 5.0
here.

	Suggest you try to verify this with sar -v.  That might be kind of
tough though, if 'commands' are not found.  You could, however,  recreate
the problem, bump the appropriate parameter, then see if the problem goes
away.

	Anyway, thats my opinion, for what it's worth.  Hope this isn't
a red herring.

Good Luck,
John Carpenter







    -----------------------------

The message is from falloc() in fio.c and means your UN*X has run out of file
descriptors.  You should also get a ENFILE error out of failing system call.
This is a consequence of the longstanding lack of dynamic storage allocation
in UN*X.
							--- Tovar




'No file' means that the kernel is out of space in the open file table.

There are two tables associated with open files: The inode table and
the open file table. The inode table stores information from the inode
as it appears on disk, more-or-less what 'ls -l' shows you.

The open file table contains a pointer to the inode table, and the current
position of a file. So, if you open /etc/passwd and I open it,
we have two different open file entries. However, if I open /etc/passwd
and then fork(), parent and child share the entry.

So, what happens is that there are too many distinct files open at
the same time. How this happens is hard to say, do a 'ps', and see
wether you see anything funny, like multiple getty's hanging on ther
same tty line, or some such.

What to do about it is easy, if you have source: increase NOFILE.
At least, that's what it was called under V7, I'm not sure wether
the name is the same under 4.2 or S5.
--
	Jack Jansen, jack at mcvax.UUCP
	The shell is my oyster.




UNder 4bsd the message is "file: table is full" It occurs in falloc()
while trying to allocate a file structure for a user process.  It
means there are over NFILE open files in your system  -- NFILE being defined
in
one of the system include files in /sys/h

Robert Perlberg
Resource Dynamics Inc.
New York
{philabs|delftcc}!rdin!perl