Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!clyde!burl!codas!killer!jfh
From: jfh@killer.UUCP (The Beach Bum)
Newsgroups: comp.unix.wizards,comp.unix.questions
Subject: Re: ulimit's (was "Re: Another Annoying Microport Inquiry")
Message-ID: <1731@killer.UUCP>
Date: Sun, 4-Oct-87 04:08:45 EDT
Article-I.D.: killer.1731
Posted: Sun Oct  4 04:08:45 1987
Date-Received: Wed, 7-Oct-87 06:48:30 EDT
References: <1408@dasys1.UUCP> <6475@brl-smoke.ARPA> <926@sauron.Columbia.NCR.COM>
Organization: Big "D" Home for Wayward Hackers
Lines: 62
Keywords: Microport patch ulimit
Summary: RTFM and follow the discussion
Xref: mnetor comp.unix.wizards:4686 comp.unix.questions:4399

In article <926@sauron.Columbia.NCR.COM>, campbell@sauron.Columbia.NCR.COM (Mark Campbell) writes:
> In article <7501@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes:
> >In article <6475@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
> >
> >|ATTENTION ALL UNIX PORTERS:  Fix this!!  A 1Mb default ulimit is absolutely
> >|stupid!  Make the initial ulimit "infinite" (it can always be lowered by
> >|any user, typically in /etc/profile if the system administrator so chooses,
> >|but only a superuser can raise it).
> 
> 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.  Thus a 1M default
> "ulimit" value is *not* stupid if the machine in question will default to
> a fairly large number of processes but a small amount of swap space.
> -- 
> 						Mark Campbell
> 						{}!ncsu!ncrcae!sauron!campbell

I'm not sure Doug Gwyn had anything to do with so, but I left his name in
anyway.  This Mark Campbell bozo needs the brain box checked out, though.

Mark - you lose credibility in this group when you don't follow the
discussion.  Jumping from file ulimits to data segment ulimits is really
the move of a complete bonzo.  It is possible to set the ulimit for a
file without changing the maximum break.  Try reading unlimit(2), that is
if the brain still can handle reading.

Now to address the issue.

Generally speaking there is no need to change the system wide ulimit in
the kernel for systems around System III, and given that ulimits weren't
in Version 7, I think that covers all bases.  The general trick is to
create a version of getty that is a stub, or change your entris in
/etc/inittab so that the ulimit setting routine is called before the
real getty.

Here is the code (totally untested) for the `execute the arguments after
the program name' version.  Real hard stuff ...  An entry of the form

01:2:respawn:/etc/setulimit /etc/getty /dev/tty01 9600

in /etc/inittab should work just fine ...

--
main (argcnt, argvec, envvec)
int argcnt;
char **argvec;
char **envvec;
{
 ulimit (2, 32000);  /* 32000 blocks should do it ... */
 execve (argvec[1], &argvec[1], envvec);
 exit (127);
}
--
Ain't that sweet ...

- John.
-- 
John F. Haugh II		HECI Exploration Co. Inc.
UUCP:	...!ihnp4!killer!jfh	11910 Greenville Ave, Suite 600
"Don't Have an Oil Well?"	Dallas, TX. 75243
" ... Then Buy One!"		(214) 231-0993