greyham@hades.OZ (Greyham Stoney) (01/17/90)
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 */
cpcahil@virtech.uucp (Conor P. Cahill) (01/17/90)
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 | +-----------------------------------------------------------------------+
sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) (01/17/90)
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
joe@junkyard.UUCP (Joseph Sarkes) (01/18/90)
ulimit is set by the kernel for all programs using the compiled in value. This is set in the configuration file (stune) or whatever your system uses. since login runs as root, it can take the default value and raise it. a process started by cron is not started by login, thus it does not get its ulimit raised before running. thus is is necessary to have the stune value of ulimit as high or higher than the default login value for cron to work right, or you can change the cron prototype if that works better for you. Joseph Sarkes (junkyard!joe)