Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!metro!nuts!cerberus!Sm
From: Sm@cerberus.bhpese.oz.au (Scott Merrilees)
Newsgroups: comp.sys.att
Subject: Re: ULIMIT
Message-ID: <1990Dec9.235816.5400@cerberus.bhpese.oz.au>
Date: 9 Dec 90 23:58:16 GMT
References: <1454@msa3b.UUCP> <140@genco.bungi.com> <1990Dec8.010027.23461@cfctech.cfc.com>
Organization: BHP, Newcastle, Australia
Lines: 19

kevin@cfctech.cfc.com (Kevin Darcy) writes:
>Anyhow, assuming the self-config reboot has been done, and your system has 
>generated a new /unix, etc., I don't know of any quick and easy way of 
>verifying that your new ulimit has "taken" (does anybody?).

I use crash(1m), and examine the u structure of a process.  The ulimit
is displayed in the file i/o section.  This is on a 3b2/600 under
V.3.1.1.  Unfortunately, I also have V.2.x.x running on some machines,
and for consistancy I change to default ulimit on all machines by
having a front end program to init, which sets an appropriate ulimit,
then exec's the real init.  The only problem with this is that cron
seems to set the ulimit back down, which is irritating, but solvable
using a setuid root program that sets the specified ulimit, then
exec's the specified command.

Sm
-- 
Scott Merrilees, BHP Information Technology, Newcastle, Australia
Internet: Sm@bhpese.oz.au                    Phone: +61 49 402132