Xref: utzoo comp.unix.i386:2347 comp.unix.wizards:20181
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!cluster!ultima!hades!greyham
From: greyham@hades.OZ (Greyham Stoney)
Newsgroups: comp.unix.i386,comp.unix.wizards
Subject: "bad ulimit" on all non-root "at" & "batch" jobs under 386/ix
Message-ID: <558@hades.OZ>
Date: 16 Jan 90 19:37:11 GMT
Organization: Ausonics Pty Ltd, Sydney, Australia
Lines: 27

Our system has suddenly, and for no apparent reason, started rejecting all
jobs from "at" and "batch" by users other than root with the error message
"bad ulimit" mailed back to the user when the command is run.

The problem appears to be in setting up the batch environment to be the
same as the one in which the job was queue'ed. Our /etc/default/login
contains:
	ULIMIT=99999
(to make filesize effectively unlimited).

Then, the /usr/lib/cron/.proto file has an entry:
	ulimit $l
(to set the ulimit the same as when the batch job was queued).

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?.

Thanks, Greyham.

-- 
/*  Greyham Stoney:                            Australia: (02) 428 6476  *
 *     greyham@hades.oz  - Ausonics Pty Ltd, Lane Cove, Sydney, Oz.      *
 *                ISDN: Interface Subscribers Don't Need                 */