Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!tut.cis.ohio-state.edu!att!cbnews!grs
From: grs@cbnews.ATT.COM (gregg.r.siegfried)
Newsgroups: comp.bugs.sys5
Subject: Re: ulimit -- You don't need sources! (kind of long)
Keywords: sources, C
Message-ID: <6218@cbnews.ATT.COM>
Date: 3 May 89 23:36:15 GMT
References: <836@twwells.uucp> <4428@ihuxz.ATT.COM> <545@aurora.AthabascaU.CA> <8305@chinet.chi.il.us> <5627@xyzzy.UUCP>
Reply-To: grs@cblph.ATT.COM (Gregg Siegfried)
Distribution: usa
Organization: AT&T Bell Laboratories
Lines: 35
Followup-To:

In article <5627@xyzzy.UUCP> duncan@rtp48.dg.com (W. Lee Duncan) writes:
>Simply move /bin/login to, e.g. /usr/lib/old_login (and make it non-setuid).
>Then, create a new /bin/login program (which will be setuid to root):

[ C program that raises ulimit and invokes login mostly deleted ]

>        ulimit(SOME_BIG_NUMBER);            /* set some big ulimit */
         ulimit(2,SOME_BIG_NUMBER);          /* would probably work better */

Aside from the minor correction above, this approach does work.  It does
have some minor tradeoffs, however.  The problem I've always had with this
is that all user processes (or the ones in your "database") have a higher
ulimit, while all the non-login processes retain the 1K ulimit.  If you
use the at(1) command (is "at(1) command" redundant BTW? :-), you'll have
to alias "at" to "ulimit 2048;/usr/bin/at $*" since at tries to reproduce
the environment of the user submitting the job (oohh that sounds IBMish)
exactly, and because your at job is running with the cron daemon's 1 
Meg ulimit, it will fail in its attempt to raise it to SOME_LARGE_NUMBER,
and the only work it will do is send you a mail message reading
something like "ulimit: bad number".  I was always a stickler for 
consistency and used the CDLIMIT define in sys/param.h to raise the 
thing globally.  But, I guess a lot of people don't have that luxury.

The last time I observed anyone using a front end to login to raise
the ulimit, and thus the at(1) problem, was with SVR2, but that would
make sense because starting with SVR3, ulimit became a tunable, and 
people quit thinking of silly things to do to raise it.

It was a fairly easy to fix cron to stop the unpleasant at behavior,
as I recall, but in practice most people stuck with raising the 
ulimit in /etc/rc before cron was started.  Yeah!  Raise it in
TWO places.  Now THAT's elegant. ;-)

Gregg Siegfried
Speaking for myself, of course..