jpn@genrad.uucp (John P. Nelson) (04/13/89)
>The newer system permit ulimit to be defined at a higher limit. And putting >the ulimit in the profile makes sense (to me at least) on a system like that. Excuse me, perhaps I'm slow. But could someone please explain to me just what the PURPOSE of "ulimit" is? What are it's GOOD points? It strikes me as a misfeature, one whose elimination would benefit EVERYONE. I mean, it's not a quota system, users can still fill the disk with lots of files smaller than the ulimit. What could POSSIBLY have been going through the minds of the developers at AT&T: "Let's add something to the system that adds no value but will frustrate everyone who ever runs into it. And while we're at it, we'll make the default setting too small, and make it so that only root can change the setting, and then, only on a process-by-process basis." It sounds like something a COMPETITOR would try to sneak in, like industrial sabatoge! Despite the tone, I really would be happy if someone could demonstrate a useful purpose for "ulimit". john nelson UUCP: {decvax,mit-eddie}!genrad!jpn smail: jpn@genrad.com
terry@eecea.eece.ksu.edu (Terry Hull) (04/18/89)
In article <19516@genrad.UUCP> jpn@genrad.genrad.COM (John P. Nelson) writes: > >Excuse me, perhaps I'm slow. But could someone please explain to me >just what the PURPOSE of "ulimit" is? What are it's GOOD points? 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. In general, a quota system does not keep users from filling up file systems either. We have a VAX 11/750 running VMS with quotas. We have approximately 3X more disk space allocated to users than we have on the machine!!!! -- Terry Hull Department of Electrical and Computer Engineering, Kansas State University Work: terry@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!terry Play: tah386!terry@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!tah386!terry
bill@twwells.uucp (T. William Wells) (04/18/89)
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.)guy@auspex.auspex.com (Guy Harris) (04/18/89)
>>Excuse me, perhaps I'm slow. But could someone please explain to me >>just what the PURPOSE of "ulimit" is? What are it's GOOD points? > >It is designed to keep processes from accidentally filling up file >systems. Fine. Did it has to be implemented so obnoxiously to achieve that goal? I've seen posting after posting complaining that the ulimit was too low, and that it was painful to crank it up. It would have been a lot better had the default been "infinity" rather than 1MB; if somebody actually *does* want to limit their program's disk consumption, they can set a non-infinite ulimit themselves. >In general, a quota system does not keep users from filling up file >systems either. We have a VAX 11/750 running VMS with quotas. We >have approximately 3X more disk space allocated to users than we have >on the machine!!!! Right. And a speed governor doesn't keep people from speeding if you set it to 180MPH.... What do you *expect* if you set your quotas up so that the sum of the quotas adds up to 3 times the amount of disk space you have?
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/18/89)
In article <19516@genrad.UUCP> jpn@genrad.genrad.COM (John P. Nelson) writes: >Despite the tone, I really would be happy if someone could demonstrate >a useful purpose for "ulimit". It's great for testing whether your application recovers gracefully from "file system full"-like conditions!
sethr@cunixc.cc.columbia.edu (Seth Robertson) (04/19/89)
In article <10065@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: |In article <19516@genrad.UUCP> jpn@genrad.genrad.COM (John P. Nelson) writes: ||Despite the tone, I really would be happy if someone could demonstrate ||a useful purpose for "ulimit". | |It's great for testing whether your application recovers gracefully from |"file system full"-like conditions! There's a *much* better way to determine in your application recovers gracefully from "file system full"-like conditions, and thats to fill up your file system. I don't know about you, but I've never had *any* problem testing that condition (whether I wanted to or not!) -Seth seth@ctr.columbia.edu
doug@letni.LawNet.Com (Doug Davis) (04/19/89)
In article <10065@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <19516@genrad.UUCP> jpn@genrad.genrad.COM (John P. Nelson) writes: >>Despite the tone, I really would be happy if someone could demonstrate >>a useful purpose for "ulimit". > >It's great for testing whether your application recovers gracefully from >"file system full"-like conditions! We use it to find out how smart our new hire'ies are, set theirs real low and see how long it takes for them to figure it out. -- Doug Davis/LawNet/1030 Pleasant Valley Lane/Arlington/Texas/76015/817-467-3740 {sys1.tandy.com, motown!sys1, uiucuxc!sys1 lawnet, killer, texbell} letni!doug Same siggie, .9832% less filling..
blh@PacBell.COM (Brian Holliday) (04/19/89)
In article <1456@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: > >>Excuse me, perhaps I'm slow. But could someone please explain to me > >>just what the PURPOSE of "ulimit" is? What are it's GOOD points? > > > >It is designed to keep processes from accidentally filling up file > >systems. > > Fine. Did it has to be implemented so obnoxiously to achieve that goal? > I've seen posting after posting complaining that the ulimit was too low, > and that it was painful to crank it up. It would have been a lot better ^^^^^^^ > had the default been "infinity" rather than 1MB... This is a painless way to up the ulimit, if you feel the default is too low. I think it is portable across all System V UNIXes. In /etc/rc (or /etc/rc2), put: ulimit 32767 ...which will increase the ulimit for all processes when the system goes into multi-user. And then, for the getty/login processes, make entries in the /etc/inittab like this: t002:2:respawn:sh -c "ulimit 32767;exec /etc/getty tty002 1200" Single-user logins will still have the default ulimit, but since this should always be the root login, and root can easily up the ulimit, there's no problem. Brian Holliday (...!pacbell!pbhyf!blh)
terry@eecea.eece.ksu.edu (Terry Hull) (04/19/89)
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. I installed a program called newlimit that allows normal users to increase the ulimit on a particluar process. That process can be their shell if they choose, but I certainly do not recommend doing that. The only time we have a problem with a 1 MB ulimit is when we are dealing with archives. -- Terry Hull Department of Electrical and Computer Engineering, Kansas State University Work: terry@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!terry Play: tah386!terry@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!tah386!terry
rwhite@nusdhub.UUCP (Robert C. White Jr.) (04/19/89)
in article <19516@genrad.UUCP>, jpn@genrad.uucp (John P. Nelson) says: > Despite the tone, I really would be happy if someone could demonstrate > a useful purpose for "ulimit". While I can make no calim about the reason the default size being what it is, the ulimit is a distinctly useful concept. Remembering that UNIXis a software development environment (at least in it's historical role) the idea of having a curb agains a single file undergoing runaway growth make alot of sense. IF you are expecting a system to produce a small file, say 4k, the ability put a choke of 40k on it has some real use and value (including the fact that the program itself can lower the threshold but not raise it.). Since root can set it to anything it wants, it is flexable enough for just about any useage environment. The real flaw in the ulimit idea is that there is (was) no good way to set the default to something other than the compiled value. The tuneable parameter was a good idea that got rid of most of the problem in most useages, as was the login-hack before it (abet a bit ugly), but the continued lack of an by-account limiting mechanisim (say adding a field to /etc/shadow which will allow login to adjust the accounts ulimit setting if the field is not blank) is still a bit inexcuseable. Rob.
bill@twwells.uucp (T. William Wells) (04/19/89)
In article <1423@cunixc.cc.columbia.edu> seth@ctr.columbia.edu (Seth Robertson) writes: : In article <10065@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: : |It's great for testing whether your application recovers gracefully from : |"file system full"-like conditions! : : There's a *much* better way to determine in your application recovers : gracefully from "file system full"-like conditions, and thats to fill : up your file system. If I decided to fill up any file system on my work machines, I'd be fired the second time I tried it. If I filled up either partition on my home machine, it would very likely break something. I suspect that there are very few environments where it is reasonable to fill up file systems just because you want to test out "file system full" checking. --- 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.)
prc@tslanpar.UUCP (prc) (04/20/89)
> It would have been a lot better had the default been "infinity" rather > than 1MB; if somebody actually *does* want to limit their program's > disk consumption, they can set a non-infinite ulimit themselves. Fortunately (for system administrators), the ulimit size cannot be increased if the effective user id is not super-user. Trying this will cause ulimit to fail and leave the value unchanged. Other users may only decrease their ulimit size. _^_ ||| Pat "King of the Trenches" Calhoun <o o> | Systems and Communication /\/\/\/\/\ Technical Support Group, Lanpar Tech. UUCP: ...!attcan!nebulus!tslanpar!mslanpar DISCLAIMER: "Read the DAMN manual, I don't need this SHIT!!"
pat@mslanpar (Pat "King of the Trenches" Calhoun) (04/20/89)
SORRY FOR THE REPOST ! PREVIOUS ARTICLE HAD WRONG UUCP PATH !! In article <1456@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: > It would have been a lot better had the default been "infinity" rather > than 1MB; if somebody actually *does* want to limit their program's > disk consumption, they can set a non-infinite ulimit themselves. Fortunately (for system administrators), the ulimit size cannot be increased if the effective user id is not super-user. Trying this will cause ulimit to fail and leave the value unchanged. Other users may only decrease their ulimit size. _^_ ||| Pat "King of the Trenches" Calhoun <o o> | Technical Support Group, Lanpar Technologies /\/\/\/\/\ UUCP: ...!attcan!nebulus!tslanpar!mslanpar DISCLAIMER: "Read the DAMN manual, I don't need this SHIT!!"
pat@mslanpar (Pat "King of the Trenches" Calhoun) (04/20/89)
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!) To ease the burden of having a low ulimit size as a global default. I have written up new shell which will scan for the user's name in a config file which also contains the value to be used for that particular user. You might want to try this, or modify the 'inittab' entry to look something like this: ttyxx:nnn:respawn:sh -c 'ulimit nnnn; exec /etc/getty ...' This will set the ulimit size for that particular port regardless of the effective user id. _^_ ||| Pat "King of the Trenches" Calhoun <o o> | Technical Support Group, Lanpar Technologies /\/\/\/\/\ UUCP: ...!attcan!nebulus!tslanpar!mslanpar DISCLAIMER: "Read the DAMN manual, I don't need this SHIT!!"
flint@gistdev.UUCP (04/20/89)
If what everyone here has been saying about the purpose of ulimit is true,
then it is "broken" under RFS. Why? Because it is the kernel that enforces
the ulimit, not the file system: that means that I can have two machines in
a network with file systems from each mounted on one another, let's call
them "big" and "small". Machine "big" has a ulimit of 32767, machine "small"
still has the 1MB default ulimit because it's file systems are all 95% full.
So what happens if someone that is logged into machine "big" writes a file
into a file system that actually physically resides on "small"? It uses the
ulimit of "big", that's what, and it fills up the file system. Similarly,
someone logged into "small" cannot create large files on "big".
Flint Pellett, Global Information Systems Technology, Inc.
1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165
INTERNET: flint%gistdev@uxc.cso.uiuc.edu
UUCP: {uunet,pur-ee,convex}!uiucuxc!gistdev!flintcgh018@tijc02.UUCP (Calvin Hayden ) (04/21/89)
> >>Excuse me, perhaps I'm slow. But could someone please explain to me > >>just what the PURPOSE of "ulimit" is? What are it's GOOD points? > > > >It is designed to keep processes from accidentally filling up file > >systems. > > Fine. Did it has to be implemented so obnoxiously to achieve that goal? > I've seen posting after posting complaining that the ulimit was too low, > and that it was painful to crank it up. It would have been a lot better > had the default been "infinity" rather than 1MB; if somebody actually > *does* want to limit their program's disk consumption, they can set a > non-infinite ulimit themselves. If you have source, it doesn't have to be 1MB. Our limit is 2MB. The change was made in the /usr/include/sys/param.h file. The line ..#define CDLIMIT (1L<<11) /* for 1mb limit */ was changed to ..#define CDLIMIT (1L<<12) /* for 2mb limit */ 'Course, this is SysV Rel2 Ver2 source, and the change does require the building of a new kernel. ============= Calvin Hayden =============
rwhite@nusdhub.UUCP (Robert C. White Jr.) (04/21/89)
in article <10075@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) says: > > Funny how the originators of UNIX, software developers par excellence, > haven't decided to add ulimit to their own systems then. Funny, I was under the impression that they had; it had a strange name though ... (reaching through the mists of time) ... I think they called it ULIMIT or something [0.5 ;-)] ulimit was and is a good idea even if it does tend to burn the unwary... I don't have a problem with it because it has saved much more trouble than it ever caused. I am glad that they are making it easier to alter in more recient releases, but it never took more than "a little care and planning" anyway. If a comercial package runs into ulimit a lot I tend to think that the designers were lax in the planning and fore- thought department... but that's just me. Rob. P.S. most UNIX systems I have worked with have a 2MB ulimit, not 1MB; but that really is neither here nor there.
rwhite@nusdhub.UUCP (Robert C. White Jr.) (04/21/89)
in article <1021@quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) says: > > Agreed, that's a handy facility which several operating systems support. > BUT you want to do that on a per-file basis. If I want to write one 1M > file and 16 4k files, I have to have ulimit high enough for the worst > case, so I may end up writing 17Mb by mistake. You could have a limit > associated with a process which was inherited by each fd opened for > output by that process, with the ability to set it down on each fd. The problem with this is that the code in the debug version would be substancially different than the eventual release material (changing limits if any and whatnot). I beleive that the general limit is a better idea because it allows for *uniform* and *scaled* runaway growth patterns to be more easily perceived. By setting the limit at a reasonably high value and providing this as a "hard failure" point you can better trace your problem... e.g. Were you to set a 1.3MB limit on your 1M file, and a 5K limit on your 4K files then if the runaway condition "peeked" one file first (in say a round robbin processing scheme, or dynamic schedule handeler) you would be pointed at a spesific file. This data would be congruent to the generall threshold concept except in some of the more obscure finery. That is to say, a general termination-condition falure might yeild => 2MB & 16x8k files (by double processing) but if one of those files were terminated at a 5k juncture and it were the first polled event or something, you would be chasing after a singel file problem. Similar datum are avalable by observing 1x1MB 12x4K 3x1.6MB and 1x2MB file sets; such datum being limited by individual thresholds. The small limit for inital development; large limits for dynamic testing; and instalation limits for final product -- type development paths do tend to produce strong code and procedure. Leastwise it never did me any harm. Rob.
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/21/89)
In article <133@tslanpar.UUCP> prc@tslanpar.UUCP (prc) writes:
-> It would have been a lot better had the default been "infinity" rather
-> than 1MB; if somebody actually *does* want to limit their program's
-> disk consumption, they can set a non-infinite ulimit themselves.
-Fortunately (for system administrators), the ulimit size cannot be
-increased if the effective user id is not super-user. Trying this
-will cause ulimit to fail and leave the value unchanged. Other
-users may only decrease their ulimit size.
You seem to miss the whole point. We KNOW that's how "ulimit" is
currently set up. We claim that that is a MISTAKE. The purpose of
computers systems is not to make system administrator's happy, it's
to meet real user requirements. Saying that it is "fortunate" that
users cannot conveniently get their needs met is really perverse.bill@twwells.uucp (T. William Wells) (04/21/89)
In article <119@mslanpar> pat@mslanpar (Pat "King of the Trenches" Calhoun) writes: : In article <1456@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: : : > It would have been a lot better had the default been "infinity" rather : > than 1MB; if somebody actually *does* want to limit their program's : > disk consumption, they can set a non-infinite ulimit themselves. : : Fortunately (for system administrators), the ulimit size cannot be : increased if the effective user id is not super-user. Trying this : will cause ulimit to fail and leave the value unchanged. Other : users may only decrease their ulimit size. So what? If I want to create a gigabyte of data when I have a megabyte ulimit, all I have to do is create 1024 1Meg files. Easy. What you are talking about here is some kind of quota system, one which limits the total amount of disk space allocatable by one user. That is completely different from ulimit. Ulimit is a safety belt, nothing more. It is of no use to system administrators, except in that the administrator *may* have fewer accidental file system fillups to clean up after. --- 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.)
bill@twwells.uucp (T. William Wells) (04/21/89)
In article <120@mslanpar> pat@mslanpar (Pat "King of the Trenches" Calhoun) writes: : 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. Really? I know of few safety devices that can't be overridden by their users. And I hardly find safety belts to be useless just because some users can choose to not put them on. So much for that speciousness. : 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!) A better analogy than a seat belt would be a glare protector that prevents you from seeing out half the front wiindow. :-) However, the point is this: if you want to run a shop where the user is presumed to be stupid or malicious till proven otherwise, you might want to hedge him round with all kinds of restrictions. You might, in such a case, be able to argue that making ulimit restricted to superuser is a good idea; I'd argue that giving users access to the shell in such a circumstance merely demonstrates the stupidity of the system administrator. Under those circumstances, you don't let the users run shells, you let them run applications only. And those applications should have whatever restrictions you need built in. You might argue that, e.g., in a university environment, you have users who might be stupid or malicious, who you need to give a shell to, and you need ulimit to keep them in line. My response would be: bull. Having ulimit be privileged won't do squat to protect you from such users. You need quotas. And on more than just disk space. If, on the other hand, you are running a system where people are doing work that requires a shell, you'd *better* have users who can make informed decisions on when to set ulimit up or down. And in that case, you don't want ulimit privileged. In short, having ulimit be privileged fails to prevent the stupid or malicious from buggering your system and may prevent the competent from doing their job. Thus ulimit shouldn't be privileged. --- 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.)
ok@quintus.UUCP (Richard A. O'Keefe) (04/21/89)
In article <120@mslanpar> pat@mslanpar (Pat "King of the Trenches" Calhoun) writes: >In article <827@twwells.uucp>, bill@twwells.uucp (T. William Wells) writes: >> 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!!! :=) > ..., 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!) Yes, but ulimit doesn't help with that. (Actually, ulimit also reports the maximum break, and does some other things too these days.) Let ulimit be 1M. All that means is that no one file I create can be bigger than that. There is nothing to stop me creating 500 1/2Mb files! My experience may not be typical, but I don't think I've ever had a disc fill up on me due to a single file being too big, in every case it has been too many smallish junk files cluttering up the place. The only time I've ever noticed the existence of ulimit has been when uucp has mysteriously lost or truncated things. In fact things like news are a good example of how ulimit fails to help: you get thousands of small files each of which ulimit is perfectly happy with. If the default ulimit had been infinity (with ordinary users only being able to decrease it), any sysadmin who wanted the present state of affairs could have done it with one line in /etc/profile, and sites that didn't want to know about it wouldn't have had file transfers die mysteriously.
ok@quintus.UUCP (Richard A. O'Keefe) (04/21/89)
In article <1325@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: >in article <1021@quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) says: >> BUT you want to do [ulimit] on a per-file basis. >The problem with this is that the code in the debug version would be >substantially different than the eventual release material (changing >limits if any and whatnot). Why? How can I call my program debugged if I haven't tested it on a couple of real data sets as well as the tests I happened to think of? >I believe that the general limit is a >better idea because it allows for *uniform* and *scaled* runaway >growth patterns to be more easily perceived. My point is that the problem with a general limit is that it doesn't allow some common failure modes to be detected *at*all*. Returning to by 1M -vs- 4k file, if there is a mistake in my program such that each record for the 4k file is being written 20 times, I'm going to use a fair bit of disc space I didn't intend to. "Uniform and scaled runaway" is not the only kind, you know. Note that my proposal has ulimit as a special case, so having a per-file limit inherited from a per-process value but settable down by fcntl() would reduce to the present scheme if you didn't choose to use that fcntl(). >The small limit for initial development; large limits for dynamic testing; >and installation limits for final product -- type development paths >do tend to produce strong code and procedure. Test what you can as soon as you can on real data, that's my motto.
chris@mimsy.UUCP (Chris Torek) (04/21/89)
The mistake is not the existence of ulimit (although there are those who would argue this as well). The mistake is that the default limit is set to such a tiny value. If the default limit were, say, 100 exabytes,% it would not be such a problem. The default file size limit should be `unlimited'; sysadmins should be able to raise and lower it, and users should be able to lower it. ----- % This is not `100 8mm tape drives': `exa' is a metric unit. If I have not got them backwards, the order is kilo, mega, giga, tera, peta, exa. (In the other direction we have milli, micro, nano, pico, femto, atto. These are abbreviated as k/M/G/T/P/E and m/u/n/p/f/a respectively. And `b' is bits; `B' is bytes; `mb' is millibits. But I see my footnote has digressed.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
chris@cetia4.UUCP (Christian Bertin) (04/21/89)
In article <10075@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > In article <1319@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: > >Remembering that UNIXis a software development environment (at least > >in it's historical role) the idea of having a curb agains a single file > >undergoing runaway growth make alot of sense. > > Funny how the originators of UNIX, software developers par excellence, > haven't decided to add ulimit to their own systems then. Ulimit also introduced the first limitation on 'root'. Having a system-wide ulimit is a mistake, having one (and the same one) for root is much worse. Chris -- Chris Bertin | -- CETIA -- 150, Av Marcelin Berthelot, Z.I. Toulon-Est +33(94)212005 | 83088 Toulon Cedex, France | inria!cetia!chris
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (04/21/89)
I think ulimit exists so that AT&T representatives can claim, without
the slightest trace of a giggle, that System V has a disk quota
mechanism.
--
Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesihenry@utzoo.uucp (Henry Spencer) (04/22/89)
In article <1324@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: >> Funny how the originators of UNIX, software developers par excellence, >> haven't decided to add ulimit to their own systems then. > >Funny, I was under the impression that they had... Please cite chapter and verse. It certainly didn't exist in any Unix system that came from Thompson and Ritchie. Are you arguing that somebody else can be called the "originators of UNIX"? Who? -- Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology 2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
plocher%sally@Sun.COM (John Plocher) (04/22/89)
In all this talk about ULIMIT don't forget that there is at least one known bug in the AT&T SVr[23] implementation: Kids, don't do this at home. login: guest password: xxxxx % su password: xxxxxxx # cp /etc/passwd /etc/passwd.old # exit % ulimit 0 % passwd old password: xxxxx new password: yyyyy Please retype new password: yyyyy % ls -l /etc/passwd* -rw-r--r-- 1 root 0 Apr 3 10:44 /etc/passwd -rw-r--r-- 1 root 439 Apr 3 10:40 /etc/passwd.old % su password: xxxxxxx # cp /etc/passwd.old /etc/passwd Note that the password file is now gone - aren't we glad we saved a copy? :-) The vendors out there may have this fixed in their versions by now... -John Plocher
john@frog.UUCP (SuperUser) (04/22/89)
In article <829@twwells.uucp>, bill@twwells.uucp (T. William Wells) writes: > In article <1423@cunixc.cc.columbia.edu> seth@ctr.columbia.edu (Seth Robertson) writes: > : In article <10065@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > : |It's great for testing whether your application recovers gracefully from > : |"file system full"-like conditions! > > [no, fill a file system] > I suspect that there are very few environments where it is reasonable > to fill up file systems just because you want to test out "file > system full" checking. However, using ulimit() to test that makes it harder to discover that your application recovers from that by creating another file and logging a message to it. If you aren't going to buy enough hardware to properly test your software, why bother with testing at all? -- John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu
guy@auspex.auspex.com (Guy Harris) (04/22/89)
> WARNING: NO SPACE ON DISK 0 PARTITION 0!!! :=) Something that a non-infinite "ulimit" will *not* always prevent, although a non-infinite "ulimit" *will*, more often than one would like (as demonstrated by the complaints made against the default "ulimit" you get in S5 as shipped by AT&T), get in the way of *legitimately* writing large files. > 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. Wrongo. Since the "ulimit" is not an appropriate mechanism to prevent a disk from filling up in general - you can fill up a 20MB disk with 20 1MB files as easily, if not *more* easily, than you can fill it up with one 20MB file, and over time you can probably even fill it up with 200 100KB files - the purpose of having a "ulimit" is to prevent some program from running away, not to act as a poor substitute for a disk quota. Furthermore, since a user might well have a need to use a file larger than the system administrator, in his/her all too finite wisdom, decided was "appropriate", the appropriate way to use the "ulimit" is to give users an infinite "ulimit" and let *them* limit the size to which some *particular* program's files can grow.
pat@mslanpar (Pat R. Calhoun) (04/23/89)
In article <1034@quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) writes: > There is nothing to stop me creating 500 1/2Mb files! I cannot argue with the fact that multiple files can be created which would defeat the purpose of having a ulimit. But this will more than likely happen only if creating huge files was intentional. However, I must admit that not all user's are UNIX x-perts'... Not only once have I seen some junior programmer attempt to write a 'C' program which creates a output file. The only problem is he forgets to increase a counter. (I guess I should note that I had ulimit set up to ~4000000). Assuming it's A Friday afternoon, and he leaves the process to execute and hope to come in Monday morning to find his program works :-). Well, you're planning another 'all week-end hack session' to find that you can't even log in since the system ca't update utmp, or something of the like. I can personally say that jumping into my car to drive at the office at midnight IS A PAIN IN THE ASS!!!!!! I realize there are alot of assumptions in my statements (and NO FLAME IS INTENDED!), but a senario similar to the above has happened to me. I agree with all that ulimit is a barrier for most users, but if the user did want to take up GIGABYTES of disk space, ulimit will not stop him. To me, ulimit is a protection against users taking up GIGABTES of disk space unintentionally (or out of stupidity)!! > If the default ulimit had been infinity (with ordinary users only being able > to decrease it), any sysadmin who wanted the present state of affairs could > have done it with one line in /etc/profile, and sites that didn't want to > know about it wouldn't have had file transfers die mysteriously. After the above incident had occured to me, I learned quickly and wrote a new shell (almost same as BOURNE) except that it takes a user id and compares it in a user database which contains the users' allowable ulimit size. Since then everybody seems happy. -- "The statements above do not reflect my thoughts, but those of my employer who forces me to think this way (OR ELSE!!!!!)" _^_ ||| Pat "King of the Trenches" Calhoun <o o> | Technical Support Group, Lanpar Technologies /\/\/\/\/\ UUCP: ...!attcan!nebulus!tslanpar!mslanpar DISCLAIMER: "Read the DAMN manual, I don't need this SHIT!!"
grs@cbnews.ATT.COM (gregg.r.siegfried) (04/23/89)
In article <829@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: >If I decided to fill up any file system on my work machines, I'd be >fired the second time I tried it. >(BTW, I'm may be looking for a new job sometime in the next few ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >months. ^^^^^^ Looks like those file systems are getting a little full, eh? :-)
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/23/89)
In article <17042@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >The default file size limit should be `unlimited'; sysadmins should >be able to raise and lower it, and users should be able to lower it. I don't know why ordinary users should be prohibited from raising their own per-file size limit. "ulimit" is not a quota system.
dave@sea375.UUCP (David A. Wilson) (04/23/89)
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
friedl@vsi.COM (Stephen J. Friedl) (04/23/89)
In article <100455@sun.Eng.Sun.COM>, plocher%sally@Sun.COM (John Plocher) writes:
< In all this talk about ULIMIT don't forget that there is at least
< one known bug in the AT&T SVr[23] implementation:
<
< % su
< password: xxxxxxx
< # cp /etc/passwd /etc/passwd.old ; exit
< % ulimit 0 ; passwd
< (type old/new/again password)
< % ls -l /etc/passwd*
< -rw-r--r-- 1 root 0 Apr 3 10:44 /etc/passwd
< -rw-r--r-- 1 root 439 Apr 3 10:40 /etc/passwd.old
OK so far, we've just trashed the live copy of the password file.
< % su
< password: xxxxxxx
< # cp /etc/passwd.old /etc/passwd
Oops. su will likely fail here ("su: Unknown id: root") and you may
be stuck in a big way (can't become root, can't restore the file, can't
go to single user mode, etc.). If you try this, have a root terminal
session on a nearby terminal *before* you start.
Steve
--
Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442
3B2-kind-of-guy / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl
"I'm making a fashion statement: I'm saying I don't know how to dress." - mebill@twwells.uucp (T. William Wells) (04/23/89)
In article <130@mslanpar> pat@mslanpar (Pat R. Calhoun) writes: : In article <1034@quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) writes: : > There is nothing to stop me creating 500 1/2Mb files! : : I cannot argue with the fact that multiple files can be created which would : defeat the purpose of having a ulimit. But this will more than likely happen : only if creating huge files was intentional. However, I must admit that not : all user's are UNIX x-perts'... Not only once have I seen some junior : programmer attempt to write a 'C' program which creates a output file. The : only problem is he forgets to increase a counter. (I guess I should note that : I had ulimit set up to ~4000000). I don't think anyone is suggesting doing away with ulimit. I certainly am not. What I, at least, am saying, is that there isn't a good reason for preventing Joe User from upping his ulimit when he sees that it is necessary. For example, I almost never create >1M files, but once in a long while, I have to work with >25M files. On the other hand, many of the file systems I work on have <10M available. So what should my ulimit be? 1M? No. I get screwed when I need to work with the larger files. >25M? No. Because I might as well not have a ulimit in that case. The right solution is to set some global default ulimit, perhaps 1 or 2M, but permit users to change the current process's ulimit as they see fit. That way, when I need to fiddle with large files, I can change the current ulimit. And even if I forget to set it back, it gets reset the next time I log in. --- Bill { uunet | novavax } !twwells!bill
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (04/24/89)
In article <100455@sun.Eng.Sun.COM> plocher@sun.COM (John Plocher) writes: >In all this talk about ULIMIT don't forget that there is at least one known >bug in the AT&T SVr[23] implementation: > >Kids, don't do this at home. Hmmm. Can't wait to get to work where I CAN try it out :-) > % ls -l /etc/passwd* > -rw-r--r-- 1 root 0 Apr 3 10:44 /etc/passwd > -rw-r--r-- 1 root 439 Apr 3 10:40 /etc/passwd.old > % su > password: xxxxxxx How'd you do that? In the absence of a password file entry for root will su _really_ let you in? [ The answer in SVr[12?] is NO ] -- John F. Haugh II +-Quote of the Week:------------------- VoiceNet: (214) 250-3311 Data: -6272 | "When everyone else complies InterNet: jfh@rpp386.Dallas.TX.US | I will too ..." UucpNet : <backbone>!killer!rpp386!jfh +------------------- -- Doug Davis --
woods@tmsoft.uucp (Greg Woods) (04/25/89)
In article <16042@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: >In article <100455@sun.Eng.Sun.COM> plocher@sun.COM (John Plocher) writes: >>In all this talk about ULIMIT don't forget that there is at least one known >>bug in the AT&T SVr[23] implementation: >> >> % ls -l /etc/passwd >> -rw-r--r-- 1 root 0 Apr 3 10:44 /etc/passwd >> % su >> password: xxxxxxx > >How'd you do that? In the absence of a password file entry for root >will su _really_ let you in? [ The answer in SVr[12?] is NO ] Ah, so much for the good old days (BSD4.? on vax) when we used to trick various daemons into zapping /etc/passwd so that we could login as root. -- Greg A. Woods. woods@{{tmsoft,utgpu,gate,ontmoh}.UUCP,utorgpu.BITNET,gpu.utcs.Toronto.EDU} +1-416-443-1734 [h], +1-416-595-5425 [w] Toronto, Ontario, Canada
bill@twwells.uucp (T. William Wells) (04/25/89)
In article <1295@frog.UUCP> john@frog.UUCP (SuperUser) writes: : In article <829@twwells.uucp>, bill@twwells.uucp (T. William Wells) writes: : > In article <1423@cunixc.cc.columbia.edu> seth@ctr.columbia.edu (Seth Robertson) writes: : > : In article <10065@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: : > : |It's great for testing whether your application recovers gracefully from : > : |"file system full"-like conditions! : > > [no, fill a file system] : > I suspect that there are very few environments where it is reasonable : > to fill up file systems just because you want to test out "file : > system full" checking. : : However, using ulimit() to test that makes it harder to discover that your : application recovers from that by creating another file and logging a message : to it. Huh? If ulimit causes a failure, one can always create or extend another file, so long as that file is smaller than the ulimit. It is quotas that would screw you there. And if you want to test for write failure on the additional file, that too can be arranged simply enough. : If you aren't going to buy enough hardware to properly test your software, : why bother with testing at all? Don't be silly. All test environments are deficient in some way or another. It's called cost. And practicality. It is wholly useless to argue that one should have extra hardware to test an error condition when it is entirely possible and extremely easy to simulate the error condition using software. Tell me, does your testing environment include hardware that you can do things to like smoking chips to see if the OS will recover from the induced parity errors? How about an alpha-hit generator? A disk that is partly defective? An OS that crashes randomly? A user that enjoys destroying keyboards while your program is running? I thought not. Why did you make such an irrelevant, and nasty, statement? Note that followups have been directed to alt.flame. --- Bill { uunet | novavax } !twwells!bill
guy@auspex.auspex.com (Guy Harris) (04/26/89)
>In the context of a corporation, a full file system is more that an >inconvenience. It cost BIG bucks!!! Every time a system hangs because >someone filled up a file system or 20-30 users can't work for several >minutes while someone figures out the problem or a temporary space >problem causes corruption of a product being prepaired for system >testing, the company loses MONEY!!! Right. And has been pointed out many times - although "ulimit"s defenders seem not to see those messages - "ulimit" doesn't prevent this. It prevents *certain* situations from causing the file system to fill up; most of the situations I've seen where a file system filled up weren't caused by some program illegitimately running off at the mouth, though, they were caused by a program *legitimately* writing a large file, or, more often, by slow accretion of a bunch of *small* files. The corporation also loses "MONEY!!!" when somebody's trying to process a file that's larger than the ulimit, and the system won't let them.... >It is not difficult at all for the administrator to set a higher >ulimit for users that have a legitimate need, ESPECIALLY is you have >source to the login program. Oh, good grief. Are there really that many people out there aware that many, many sites do *not* have source to the login program? By this logic, "/etc/inittab" isn't really necessary; after all, it would not be difficult at all for the administrator to modify a compiled-in table.... >If you had ever been an administrator in a software development >environment you would see the demonstrated need for the ulimit. This statement is false. I've administered systems in this environment, and I see no such need.
lyndon@aurora.AthabascaU.CA (Lyndon Nerenberg) (04/26/89)
In article <4428@ihuxz.ATT.COM>, burris@ihuxz (Burris) writes: >From article <836@twwells.uucp>, by bill@twwells.uucp (T. William Wells): >The ulimit has NOTHING to do with the assumption that users are stupid >or malicious. It DOES however assume that people make mistakes. Do you >know any programmer who has NEVER hacked up a quick program with an >infinate loop? Yes. And those that do nearly always screw up a read loop, not a write loop. [ I have no numbers to back this, but I've administered a lot of machines and never seen an mistake like this fill a file system ] >It is not difficult at all for the administrator to set a higher >ulimit for users that have a legitimate need, ESPECIALLY is you have >source to the login program. I implemented this easily by having the >login program look through a file to find users that required special >ulimit sizes and set the appropriate ulimit before exec'ing the shell. That's a pretty damn big ESPECIALLY. Are you aware of the price your company charges for that source code? If I was running a commercial shop, instead of paying a small fortune for source, I would put the money to better use buying more drives for the disk farm. >If you had ever been an administrator in a software development >environment you would see the demonstrated need for the ulimit. I have, and I don't. If you're developing on a machine that you sell time on, you deserve what you get when you screw up. Yes you can turn ulimit up by reconfiguring the kernel. But how do you rationalize ulimit in a database environment where your running striped file systems with database files in the range of 2 GBytes each? As people move towards hypertext and graphics based environments, the size of the files you have to deal with will increase as well. "No problem," you say. "Just turn up the ulimit." Well I say, "When the ulimit reaches the file size limit, what is the point of having ulimit?" As a system administrator I feel that ulimit (if it's to exist) should default to the maximum possible file size (base on the inode struct). If *I* as a system administrator want to turn it down, fine. That isn't too hard to do right now :-) Going the other way isn't ...
bill@twwells.uucp (T. William Wells) (04/26/89)
In article <4428@ihuxz.ATT.COM> burris@ihuxz.ATT.COM (Burris) writes:
: The ulimit has NOTHING to do with the assumption that users are stupid
: or malicious. It DOES however assume that people make mistakes. Do you
: know any programmer who has NEVER hacked up a quick program with an
: infinate loop?
Uh, buddy, have you been reading my postings? I didn't say a thing
about eliminating ulimit. What I said was that there is no good
reason for it to be privileged. The sysadmin should set the default
value to something reasonable and assume that users won't set it up
without need. If you have users who will set their ulimits
irrationally, you also have users who won't care about filling up
your disks with lots of little files. And in that case you need
something stronger than ulimit. Like quotas.
: If you had ever been an administrator in a software development
: environment you would see the demonstrated need for the ulimit.
Hey, fathead!
Now that I've returned your insults, can we talk rationally?
I've administered many different systems. On all those systems, the
most common disk-space problem I had was that people would not clean
up the files they were responsible for. The result? Sometimes half the
disk space was taken up by files of no value to anyone.
Ulimit wouldn't have fixed this. Ulimit, in the normal course, is
good for one thing only: preventing runaway programs from filling
your disks. And for that purpose, there is no point in making it
privileged.
---
Bill { uunet | novavax } !twwells!billflint@gistdev.UUCP (04/26/89)
In several years of real world running of systems, looking at the systems that many of our clients have been running, etc., I've only seen the ulimit do any good in one case, and that is to keep /etc/utmp from filling up the root partition on a system that doesn't get watched much. However, I've seen numerous cases where the ulimit got in the way of doing real work. (If you want a useful parameter put in one that says how many entries to keep in utmp.)
les@chinet.chi.il.us (Leslie Mikesell) (04/27/89)
In article <545@aurora.AthabascaU.CA> lyndon@nexus.ca (Lyndon Nerenberg) writes: >>It is not difficult at all for the administrator to set a higher >>ulimit for users that have a legitimate need, ESPECIALLY is you have >>source to the login program. >That's a pretty damn big ESPECIALLY. Are you aware of the price your >company charges for that source code? If I was running a commercial >shop, instead of paying a small fortune for source, I would put the >money to better use buying more drives for the disk farm. Or perhaps an OS that provides per-user disk quotas (and a machine to run it on.. [notice the lack of a smiley here]) >>If you had ever been an administrator in a software development >>environment you would see the demonstrated need for the ulimit. Well, no, but you might see the need for quotas or the need to repartition your disks to provide the development environment for each project. >...Well I say, "When the >ulimit reaches the file size limit, what is the point of having >ulimit?" It's not a bad concept, and it's now a tunable, but it's not a quota system and you can't rely on it to keep you out of trouble. I suspect the real reason it exists is to keep people who do not have appropriate cron entries from filling their disks with the wtmp, cronlog, sulog etc. files. Les Mikesell
root@nebulus.UUCP (Dennis S. Breckenridge) (04/27/89)
In article <133@tslanpar.UUCP>, prc@tslanpar.UUCP (prc) writes: > > > > > It would have been a lot better had the default been "infinity" rather > > than 1MB; if somebody actually *does* want to limit their program's > > disk consumption, they can set a non-infinite ulimit themselves. > > Fortunately (for system administrators), the ulimit size cannot be > increased if the effective user id is not super-user. Trying this > will cause ulimit to fail and leave the value unchanged. Other > users may only decrease their ulimit size. > In adding more insult to injury I have several questions to ask. If you are running Unix/386 3.2.n from AT&T and have the /etc/defaults/login stuff its easy for a *USER* to get a large ulimit. What about uucico that ignores that ulimit? The shell gets passed a variable that tells it what the ulimit should be. uucico(1) does not. With a system limit of 1MB that restricts me from creating a file that is larger than 1MB with any program. Uucico gets a fail on file write and drops the connection. It then wakes up and says hmm I have this job in the queue, lets send it AGAIN. Try this one kiddies only to make mom and dad happy do it long distance. Who are you when you are creating a file in /etc? The /etc directory is protected 775 with with owner and group sys. How can you the non-sys or root user WRITE into that directory. Lets go back to Unix school and re-learn Unix administration. Who is the adminstrator on your machines? Any seasoned Unix hack knows that the ulimit is too small for *NEWER* applications. He will then retune the kernel /etc/master.d/kernel or in the 386 world /etc/conf/cf.d/stune to meet the needs of that particular installation. If he does not then get someone that KNOWS UNIX!!!! In a "hostile" environment tune your ulimit high and then modify the /etc/profile to allow "non-hostile" users to access this. The normal users then get a ulimit 2048. BTW /etc/profile is only used by the shell, so uucp (uucico) will be happy -- don't worry :-) -- ============================================================================== "A mind is a terrible thing to MAIL: Dennis S. Breckenridge waste!" 206 Poyntz Ave North York, Ontario M2N1J6 (416) 733-1696 UUCP: uunet!attcan!nebulus!dennis ICBM: 79 28 05 W / 43 45 01 N 50 megatons should do! ==============================================================================
dave@sea375.UUCP (David A. Wilson) (04/27/89)
From article <4428@ihuxz.ATT.COM>, by burris@ihuxz.ATT.COM (Burris): > The ulimit has NOTHING to do with the assumption that users are stupid > or malicious. It DOES however assume that people make mistakes. Do you > know any programmer who has NEVER hacked up a quick program with an > infinate loop? Ulimit doesn't help at all if your infinite loop creates another file on each pass. You could run out of inodes too! -- David A. Wilson uw-beaver!tikal!slab!sea375!dave
plocher%sally@Sun.COM (John Plocher) (04/27/89)
In article <863@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: >>>>>>> (many people) write: >>>>>>> (use ulimit instead of filling a file system) >Huh? If ulimit causes a failure, one can always create or extend >another file, so long as that file is smaller than the ulimit. But, with a full filesystem you can NOT "always create or extend another file" >: If you aren't going to buy enough hardware to properly test your software, > >Don't be silly. All test environments are deficient in some way or > >Tell me, does your testing environment include hardware that you can > A disk that >is partly defective? An OS that crashes randomly? Well, at Microport we did have several "bad" disks which we used to test the fault handling code in our device drivers. As to an OS which crashes randomly, well, not intentionally :-))))
mats@oblio.UUCP (Mats Wichmann) (04/28/89)
In article <17042@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > The mistake is not the existence of ulimit (although there are those > who would argue this as well). The mistake is that the default limit > is set to such a tiny value. If the default limit were, say, 100 > exabytes,% it would not be such a problem. > > The default file size limit should be `unlimited'; sysadmins should > be able to raise and lower it, and users should be able to lower it. > > ----- > % This is not `100 8mm tape drives': `exa' is a metric unit. If I have > not got them backwards, the order is kilo, mega, giga, tera, peta, > exa. (In the other direction we have milli, micro, nano, pico, > femto, atto. These are abbreviated as k/M/G/T/P/E and m/u/n/p/f/a > respectively. And `b' is bits; `B' is bytes; `mb' is millibits. > But I see my footnote has digressed.) > -- > In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) > Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris (Nice digression. A little education never hurts...) No problem? Just had to toss my own horror story into the ring: just a few weeks ago I brought up a new version of NFS, and found that clients didn't write to the old servers too good any more. Turns out this nifty little bit of code was responsible: if (u.u_offset >= (u.u_limit << SCTRSHFT)) /* don't write because you exceeded the ulimit, right? */ Now let's see. If SCTRSHFT is 10 (like on our system), (100 exabytes << SCTRSHFT) is what? What does come after exa? Or do we spell it "0" because my ints aren't that big? Needless to say, the above cited code is now a bit different... -Mats Wichmann -Acer Counterpoint, Inc.