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.