Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.questions
Subject: Re: ulimit considered braindamaged ?
Message-ID: <5486@brl-smoke.ARPA>
Date: Wed, 7-Jan-87 10:57:09 EST
Article-I.D.: brl-smok.5486
Posted: Wed Jan  7 10:57:09 1987
Date-Received: Wed, 7-Jan-87 23:03:06 EST
References: <790@maynard.BSW.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20
Keywords: ulimit SysV irksome

The 1Mb initial ulimit is without doubt the single stupidest
feature of vanilla UNIX System V.  Since only the super-user
can raise the ulimit, one cannot even fix this in his .profile.
The correct solution is to change the kernel's initial ulimit
setting to be "infinite"; it is easy enough to lower it when
so desired (e.g. in /etc/profile).  If you can't patch the
kernel, then modify init(1M) to raise the ulimit, which it can
do since it runs as super-user.  Failing that, you could try
running a "pre-login shell" that is set-UID 0, which would
simply raise the ulimit, change the UID, and exec a real shell.

By the way, users on our systems routinely process files much
bigger than 1Mb.  A 1Mb file limit doesn't make sense in any
case except for toy computers.  Come to think of it, even my
Apple //e frequently has to deal with larger files!

I don't know how one gets AT&T to remedy mistakes such as this
one; if you submit an MR you will probably be told to use some
unacceptable work-around and the matter would then be dropped
("MR resolved").  Perhaps you should nag your system vendor.