Xref: utzoo comp.unix.i386:2363 comp.unix.wizards:20191
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.i386,comp.unix.wizards
Subject: Re: "bad ulimit" on all non-root "at" & "batch" jobs under 386/ix
Message-ID: <1990Jan17.002348.11507@virtech.uucp>
Date: 17 Jan 90 00:23:48 GMT
References: <558@hades.OZ>
Organization: Virtual Technologies Inc.
Lines: 22

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. Only root can increase it's
> ulimit; so presumably cron should be starting the jobs with unlimited
> (or very large) ulimit, so that the .proto generated entry can bring it
> down to what it should be. So, what could be causing cron to start the job
> with too small a ulimit?. Or is something else wrong here?. Any ideas?.

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 or 
something like that).  Since cron is running as root, it does not 
to obey the ulimit (and any of root's cron jobs doesn't either).  However,
once the job starts up as non-root it must obey the ulimit.  

The fix for this is to modify the startup file (/etc/rc2.d/S75cron on this 
system) so that it sets it's ulimit real high before starting cron. 

-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+