Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!pacbell!pbhyf!blh
From: blh@PacBell.COM (Brian Holliday)
Newsgroups: comp.bugs.sys5
Subject: Re: ulimit (was: getty/login for callback)
Message-ID: <5051@pbhyf.PacBell.COM>
Date: 18 Apr 89 20:15:16 GMT
References: <180001@mechp10.UUCP> <13853@rpp386.Dallas.TX.US> <797@twwells.uucp> <1456@auspex.auspex.com>
Distribution: usa
Organization: Pacific * Bell, San Ramon, CA
Lines: 31

In article <1456@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes:
> >>Excuse me, perhaps I'm slow.  But could someone please explain to me
> >>just what the PURPOSE of "ulimit" is?  What are it's GOOD points?  
> >
> >It is designed to keep processes from accidentally filling up file
> >systems.
> 
> Fine.  Did it has to be implemented so obnoxiously to achieve that goal?
> I've seen posting after posting complaining that the ulimit was too low,
> and that it was painful to crank it up.  It would have been a lot better
                  ^^^^^^^
> had the default been "infinity" rather than 1MB...

This is a painless way to up the ulimit, if you feel the default is too low.
I think it is portable across all System V UNIXes.

In /etc/rc (or /etc/rc2), put:

ulimit 32767

...which will increase the ulimit for all processes when the system goes
into multi-user.  And then, for the getty/login processes, make entries in
the /etc/inittab like this:

t002:2:respawn:sh -c "ulimit 32767;exec /etc/getty tty002 1200"

Single-user logins will still have the default ulimit, but since this should
always be the root login, and root can easily up the ulimit, there's no
problem.

Brian Holliday (...!pacbell!pbhyf!blh)