Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!mcnc!ece-csc!ncrcae!sauron!campbell
From: campbell@sauron.Columbia.NCR.COM (Mark Campbell)
Newsgroups: comp.unix.wizards,comp.unix.questions
Subject: Re: ulimit's (was "Re: Another Annoying Microport Inquiry")
Message-ID: <927@sauron.Columbia.NCR.COM>
Date: Sun, 4-Oct-87 11:03:48 EDT
Article-I.D.: sauron.927
Posted: Sun Oct  4 11:03:48 1987
Date-Received: Thu, 8-Oct-87 02:02:21 EDT
References: <1408@dasys1.UUCP> <6475@brl-smoke.ARPA> <926@sauron.Columbia.NCR.COM> <29928@sun.uucp>
Reply-To: campbell@sauron.Columbia.NCR.COM (Mark Campbell)
Organization: Entry Level Systems Development, NCR Corp., Columbia, SC
Lines: 18
Keywords: Microport patch ulimit
Xref: mnetor comp.unix.wizards:4693 comp.unix.questions:4404

In article <29928@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes:
>> The default "ulimit" should be set using the default number of processes
>> and the default amount of swap space.  Careful use of "ulimit" allows one
>> to avoid getting into pathological "out of swap space" conditions.
>
>Excuse me?  How can the limit on the maximum FILE size - which is what is being
>discussed here - have any direct effect on the consumption of swap space?

Sorry...early Saturday morning knee jerk reaction.  I had just finished battling
some problems with "ulimit()" the night before -- basically a bug in the
Perennial test suite which made some assumptions concerning the use of this
system call in returning the maximum possible "brk()" value.  This, coupled with
a battle a few nights ago over another test suite which could only be fixed
by lowering MAXUMEM and the V.3.1 change in name of ULIMIT to CDLIMIT, led
to a truly strange interpretation of this message.
-- 
						Mark Campbell
						{}!ncsu!ncrcae!sauron!campbell