Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!mips!mips!sdd.hp.com!wupost!gumby!destroyer!uunet!decwrl!netcomsv!mork!hasty
From: hasty@netcom.com (Amancio Hasty Jr)
Subject: Re: proc table full? (386bsd)
Message-ID: <s7vld9.hasty@netcom.com>
Date: Sat, 27 Jun 92 19:25:32 GMT
Organization: Netcom - Online Communication Services (408 241-9760 guest)
References: <3489@wzv.win.tue.nl>
Lines: 75
In article <3489@wzv.win.tue.nl> guido@gvr.win.tue.nl (Guido van Rooij) writes:
>
>Last week it ocuured twice that my system was hanging due to a
>"vmunix: proc table full". Did anyone see this before? If patches
>are availbale, they are welcome. I don't have time working on solved
>bugs. Talking about bugs: the above mentioned one, together with
>the fact that i experienced one time that the system hung while
>constantly accessing the fixed disk (i only have 1) are the only "real"
>bugs left.
>And then there is another strange behaviour: when using wildcards on NFS
>mounted directories, it occurs frequently that commands return with error
>0. e.g. when you do a more (or grep) like "more *" on a directory with
>lots of files (100+).
>I don't understand why this doesnt work. It seems independent of the
>shell (occurs with ash, csh, tcsh). As I said, I believe this only happens
>with NFS filesystems
I believe the above may be due to kern_execve.c. Also, I have experienced
the same problem on my local disk....
>-Guido
Could some please post a list of available patches, perhaps those who are
archiving the patches.... Thank you in advance...
>From time to time I see process left in Zombie state. If you have
enough of this processes you will fill up the table... I seem to
recollect that on my system exiting tip would leave tip in a Zombie
state...
Hope the enclosed posting helps you. Please let me know how it goes...
Enjoy,
Amancio
>From mork!netcomsv!decwrl!mips!spool.mu.edu!umn.edu!math.fu-berlin.de!zrz.tu-berlin.de!news.netmbx.de!Germany.EU.net!tools!ws Sun May 17 08:50:39 PDT 1992
Article: 1354 of comp.unix.bsd
Path: mork!netcomsv!decwrl!mips!spool.mu.edu!umn.edu!math.fu-berlin.de!zrz.tu-berlin.de!news.netmbx.de!Germany.EU.net!tools!ws
From: ws@tools.de (Wolfgang Solfrank)
Newsgroups: comp.unix.bsd
Subject: Re: full proc table
Message-ID: <WS.92May17154735@kurt.tools.de>
Date: 17 May 92 13:47:35 GMT
Article-I.D.: kurt.WS.92May17154735
References: <18339.9205121502@thor.cf.ac.uk>
<MIB.92May15004939@geech.gnu.ai.mit.edu>
<QUANSTRO.92May15014123@mari.StOlaf.edu>
<MIB.92May15051657@geech.gnu.ai.mit.edu> <PACE.92May16083638@blitz.com>
Sender: news@tools.de
Organization: TooLs GmbH, Bonn, Germany
Lines: 17
Nntp-Posting-Host: kurt.tools.de
In-reply-to: pace@blitz.com's message of 16 May 92 12:36:42 GMT
In article <PACE.92May16083638@blitz.com> pace@blitz.com (Pace Willisson) writes:
(quote from the NET/2 kernel:)
if (nprocs >= maxproc || uid == 0 && nprocs >= maxproc + 1) {
tablefull("proc");
return (EAGAIN);
}
Actually this is a bug in the BSD kernel. The precedence rules parse the
above as
if (nprocs >= maxproc || (uid == 0 && nprocs >= maxproc + 1)) {
which results in the maxproc limit to be enforced for all users including
root. The above should read something like this (if you want what the comment
suggests:
if (nprocs >= maxproc && uid != 0 || nprocs >= maxproc + 1) {
which parses as (and could for clarity be written as):
if ((nprocs >= maxproc && uid != 0) || nprocs >= maxproc + 1) {
--
ws@tools.de (Wolfgang Solfrank, TooLs GmbH) +49-228-985800