Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!uflorida!novavax!twwells!bill
From: bill@twwells.uucp (T. William Wells)
Newsgroups: comp.bugs.sys5
Subject: Re: ulimit (was: getty/login for callback)
Message-ID: <827@twwells.uucp>
Date: 18 Apr 89 05:02:51 GMT
References: <180001@mechp10.UUCP> <13853@rpp386.Dallas.TX.US> <797@twwells.uucp> <28@wells.UUCP> <399@aucis.UUCP> <501@bilver.UUCP> <19516@genrad.UUCP> <628@eecea.eece.ksu.edu>
Reply-To: bill@twwells.UUCP (T. William Wells)
Distribution: usa
Organization: None, Ft. Lauderdale
Lines: 20
Summary:
Expires:
Sender:
Followup-To:
Keywords:

In article <628@eecea.eece.ksu.edu> terry@eecea.eece.ksu.edu (Terry Hull) writes:
: It is designed to keep processes from accidentally filling up file
: systems.  Here is an example:  I write a program that does a few
: calculations and writes the results to a disk file.  The program is
: supposed to terminate after 100 iterations, but I forget to increment
: the counter on the way through the loop.  The program ends up going
: through 1,000,000 iterations.  I do not even notice because I am
: running the process in the background.  With no ulimit, I can fill
: up a file system totally by accident.

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.

---
Bill                            { uunet | novavax } !twwells!bill
(BTW, I'm may be looking for a new job sometime in the next few
months.  If you know of a good one where I can be based in South
Florida do send me e-mail.)