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
tron1@tronsbox.UUCP (HIM) (01/18/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. > Actually , running ISC 2.0.2 I am looking for the way to increase the ulimit SYSTEM wide. I have a bunch of jobs that come in for uuxqt that are labiring under a ulimit of 3072 , this is NOT enough as the update a hash file that is already 1.6 meg big. I changed /etc/default but that doesnt help, and I have tried doing an "add tunable paramater" of ulimit 12288 in kconfig, did a build, but /etc/conf/cf.d/mtune still has the old value .. HELP! **************************************************************************** Everything I say is Copr. 1990, except the stuff I stole from someone else and the stuff I don't want responsibility for. Kenneth J. Jamieson: Xanadu Enterprises Inc. "Professional Amiga Software" UUCP: tron1@tronsbox.UUCP BEST PATH ---> uunet!tronsbox!tron1 Sysop, Romantic Encounters BBS - (201)759-8450 / (201)759-8568 ****************************************************************************
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)
james@bigtex.cactus.org (James Van Artsdalen) (02/02/90)
In <1990Jan30.142000.5253@virtech.uucp>, cpcahil@virtech.UUCP (Conor P. Cahill) wrote: > ulimit and quotas are two different things! Yes, quota works and ulimit does not. If it actually merely caught programs using lots of disk space, fine. That is not actually what it does. > ulimits (and BSD resource limits) are there to catch a run-away program > from eating up too much space. What ulimit actually does it prevent writing beyond a certain file offset in any regular file. There is not an absolute relationship between the file offset and the amount of data written. My original example still holds: a user posting a news article causes inews to fail writing the history file. Perfectly legimate, perfectly ordinary. Why should a ulimit-type system consider inews, writing probably less than 200 bytes to history, to be run-away? | ulimit is basically an example of what was wrong with AT&T unix (as | opposed to BSD) for a long time: no one at AT&T cared if the product | was usable/competitive or not. Someone had a file fill a filesystem > If you want to bash at&t without thinking about what you are saying, go > ahead. However you might want to know that BSD does provide the same > functionality as ulimit so they must have thought it was usefull. I not only thought about it, I suffered with the problem and went and read the source. I do confess that I didn't read the BSD source to see if they handled the resource limit stuff right. I also haven't checked to see if that resource limit is enabled by default (you can bet it won't be 1meg). If the AT&T programmer had thought correctly, they would have realized that the correct thing to do would be to (1) count blocks actually allocated so that a program would really be allowed to write it's full ulimit. It's clear that the file offset model doesn't really address the problem: it's a cheap way out. (2) the ulimit should be reset to some system default on exec(2) to an suid program. #2 raises issues about what ought to happen with sgid programs, but it's clearly solvable. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
cpcahil@virtech.uucp (Conor P. Cahill) (02/03/90)
In article <28606@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: >If the AT&T programmer had thought correctly, they would have realized >that the correct thing to do would be to (1) count blocks actually >allocated so that a program would really be allowed to write it's full >ulimit. To implement this change they would have to do one of the following: 1. change the file system inode so that it now has a slot to keep the "real" size of the file (# of used datablocks). and make the appropriate kernel stuff to keep track of this stuff and update the disk inode. This is a no-no since it would break compatability with earlier versions of the file system. 2. change the kernel code so that when a file is opened the kernel reads through the inode, single, double, and triple indirect blocks to calculate the "real" size of the file at open time. This info would be kept in the in-core inode. This could be done, but there is a considerable amount of overhead added to the system for little gain. 3. change the kernel code so that it reads through the inode, single double, and triple indirect blocks to calculate the "real" size whenever a write is attempted. You could even modify this so that it is done only when the "fake" size of the file is larger than the ulimit. This would probably have considerable larger overhead on the system than the previous method. Plus, if you implement this, you have the problem of what to do if a file is at it's limit and the user tries to write a byte into one of the holey blocks. Obviosly this write should fail but I think that error would be much harder to explain than failing at the end of the file. > It's clear that the file offset model doesn't really address >the problem: it's a cheap way out. Yes it is a cheap way out and for most cases satisfies exactly what it was designed for. I think there is always a case for setting some arbitrary limit (albeit suitably large so that it is not run into very often, if at all) for most system resources including memory and disk space. What the defaults should be is always up for argument. Considering the amount of disk space available on todays machines, I think the ulimit should be set to something like 10,000 by default. Yes I know that is my opinion and I know it is up for argument, but I think that a ulimit of 10000 would be much less likely to be run into. Of course in another 3 years when everybody has 2 or 4 GB of disk space on their pc's and small workstations, the default ulimit should be increased again. system V ulimit -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
james@bigtex.cactus.org (James Van Artsdalen) (02/06/90)
In <1990Feb3.003112.22012@virtech.uucp>, cpcahil@virtech.UUCP (Conor P. Cahill) wrote: > In article <28606@bigtex.cactus.org> james@bigtex.cactus.org (me) wrote: | If the AT&T programmer had thought correctly, they would have realized | that the correct thing to do would be to (1) count blocks actually | allocated so that a program would really be allowed to write it's full | ulimit. > To implement this change they would have to do one of the following: > > 1. change the file system inode so that it now has a slot to > keep the "real" size of the file (# of used datablocks). > and make the appropriate kernel stuff to keep track of this > stuff and update the disk inode. This sounds like much too much effort. When I said I didn't care how big the files were, just how much was written, and I meant it: file size has nothing to do with limiting a user's disk consumption. Keep a vector, indexed on uid, of how many blocks each uid allocates, incrementing the count each time a new block is allocated, decrementing on unlink. I'll go out on a limb, not having looked at this source, but I'll bet there's one place in the generic write(2) and unlink(2) code that can do this (arguably directory files should be handled too). No need to muck with the inode structure. You do need a way to initialize this structure, via login(1) I suppose. Gee, sounds more and more like quota. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789