Xref: utzoo comp.unix.i386:2370 comp.unix.wizards:20198
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!voder!wlbr!WLV.IMSD.CONTEL.COM!sms
From: sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz)
Newsgroups: comp.unix.i386,comp.unix.wizards
Subject: Re: "bad ulimit" on all non-root "at" & "batch" jobs under 386/ix
Message-ID: <44177@wlbr.IMSD.CONTEL.COM>
Date: 17 Jan 90 10:38:30 GMT
References: <558@hades.OZ> <1990Jan17.002348.11507@virtech.uucp>
Sender: news@wlbr.IMSD.CONTEL.COM
Reply-To: sms@WLV.IMSD.CONTEL.COM.UUCP (Steven M. Schultz)
Followup-To: comp.unix.i386
Organization: Contel Federal Systems
Lines: 19

In article <1990Jan17.002348.11507@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:
>In article <558@hades.OZ>, greyham@hades.OZ (Greyham Stoney) writes:
>> But, when this 'ulimit' command is ultimately run in the batch job, it
>> gets rejected with the "bad ulimit" message...
>
>Cron starts from an /etc/rc2.d file, which is run by init.  The ULIMIT in
>effect when init starts cron is the ulimit in the kernel (max at 12228...

	i must disagree.

	"ulimit" is BAD,  actually 'impish' is more descriptive - it does
	no real good, but a great deal of inconvenience and mischieve.

	the "correct" fix is to convince the purveyors of
	the product which include this brain-dead system call to remove
	it and implement disc quotas (a la 4.3/2.10.1BSD).

	Steven M. Schultz
	sms@wlv.imsd.contel.com