Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!mit-eddie!uw-beaver!uw-june!uw-entropy!quick!happym!amc!sigma!sea375!dave
From: dave@sea375.UUCP (David A. Wilson)
Newsgroups: comp.bugs.sys5
Subject: Re: ulimit (was: getty/login for callback)
Message-ID: <246@sea375.UUCP>
Date: 23 Apr 89 03:48:29 GMT
References: <120@mslanpar>
Organization: At Home in Seattle, WA
Lines: 36

From article <120@mslanpar>, by pat@mslanpar (Pat "King of the Trenches" Calhoun):
> In article <827@twwells.uucp>, bill@twwells.uucp (T. William Wells) writes:
>> This is what I heard, also. But it fails to explain why increasing
>> ones ulimit is restricted to root. If ulimit is only a safety belt,
>> there isn't any good reason for preventing one from tightening or
>> loosening it as needed.
>> 
> 
> 	WARNING: NO SPACE ON DISK 0 PARTITION 0!!! :=)
> 
> 	In most states, safety belts are not an option. With this in
> 	mind, it would be useless to have a safety device that could
> 	be overridden by anyone. This defeats the purpose of having 
> 	a ulimit.  The message above is not a fantasy, but reality,
> 	and when it does occur, it's usually a pain to clear out the 
> 	files (making sure not to get rid of anything of value!)
The problem above would be better prevented by a ulimit or quota that
applies to each filesystem separately.

One problem that a single ulimit for each user creates occurs when
that user must work with large files like databases. It is disatrous
to a database to have a write fail just because of it runs into
an ulimit that was set too small. I worked on an older System V where
there was not way to set the ulimit over 16MB! I was trying to build
large databases, but kept running into this stupid ulimit! The system
update solved this, what a relief. The ulimit idea is sometimes useful,
but it is too rigid and limited in scope for diverse system environments.
Ulimit-caused failures are not friendly or recoverable in most cases.
This behavior is what makes me feel that ulimit should be abolished and
replaced by disk quotas and possibly resource limits that can be
imposed by a process on itself(these should be used sparingly).


-- 
	David A. Wilson
	uw-beaver!tikal!slab!sea375!dave