campbell@sauron.Columbia.NCR.COM (Mark Campbell) (10/03/87)
In article <7501@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <6475@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > >|ATTENTION ALL UNIX PORTERS: Fix this!! A 1Mb default ulimit is absolutely >|stupid! Make the initial ulimit "infinite" (it can always be lowered by >|any user, typically in /etc/profile if the system administrator so chooses, >|but only a superuser can raise it). The default "ulimit" should be set using the default number of processes and the default amount of swap space. Careful use of "ulimit" allows one to avoid getting into pathological "out of swap space" conditions. Thus a 1M default "ulimit" value is *not* stupid if the machine in question will default to a fairly large number of processes but a small amount of swap space. -- Mark Campbell {}!ncsu!ncrcae!sauron!campbell
guy@gorodish.UUCP (10/04/87)
> The default "ulimit" should be set using the default number of processes > and the default amount of swap space. Careful use of "ulimit" allows one > to avoid getting into pathological "out of swap space" conditions. Excuse me? How can the limit on the maximum FILE size - which is what is being discussed here - have any direct effect on the consumption of swap space? Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
gwyn@brl-smoke.UUCP (10/04/87)
In article <926@sauron.Columbia.NCR.COM> campbell@sauron.Columbia.NCR.COM (Mark Campbell) writes: >The default "ulimit" should be set using the default number of processes and the >default amount of swap space. This is totally irrelevant! The file size ulimit causes truncation of one's file when writing past the ulimit. It has nothing to do with process size!
rcw@qetzal.UUCP (sysop) (10/04/87)
> The default "ulimit" should be set using the default number of processes and the > default amount of swap space. Careful use of "ulimit" allows one to avoid > getting into pathological "out of swap space" conditions. Thus a 1M default > "ulimit" value is *not* stupid if the machine in question will default to > a fairly large number of processes but a small amount of swap space. > -- > Mark Campbell > {}!ncsu!ncrcae!sauron!campbell I believe mark misunderstands the purpose of ulimit in Chapter two. The function is used to 1) get the file size limit of the process. 2) set the file size limit of the process to some other value. 3) Find out the maximum possible break value. The Microport product has a kludge to patch the DEFAULT ulimit size; that is, the file size limit which will be permitted when the system is booted. Therefore, a one megabyte "ulimit" is inappropriate if users are working routinely with much larger files. A particularly obnoxious implementation of changing one's ulimit can be found on the IBM-RT, where the limit for each user is specified in the password file, and by default is 65536 logical blocks. I do not see what connection ulimit has to "out of swap space" error messages or to the number of processes currently running. -- Robert C. White, Jr *---- ----* MENTOR SOFTWARE, INC. 1-303-252-9090 ihnp4!upba!qetzal!rcw | |_| | 11534 Steele St. | _ o _ | Thornton, CO 80233 | | | | | | Custom Software Specialists.
jfh@killer.UUCP (The Beach Bum) (10/04/87)
In article <926@sauron.Columbia.NCR.COM>, campbell@sauron.Columbia.NCR.COM (Mark Campbell) writes: > In article <7501@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: > >In article <6475@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > > > >|ATTENTION ALL UNIX PORTERS: Fix this!! A 1Mb default ulimit is absolutely > >|stupid! Make the initial ulimit "infinite" (it can always be lowered by > >|any user, typically in /etc/profile if the system administrator so chooses, > >|but only a superuser can raise it). > > The default "ulimit" should be set using the default number of processes and the > default amount of swap space. Careful use of "ulimit" allows one to avoid > getting into pathological "out of swap space" conditions. Thus a 1M default > "ulimit" value is *not* stupid if the machine in question will default to > a fairly large number of processes but a small amount of swap space. > -- > Mark Campbell > {}!ncsu!ncrcae!sauron!campbell I'm not sure Doug Gwyn had anything to do with so, but I left his name in anyway. This Mark Campbell bozo needs the brain box checked out, though. Mark - you lose credibility in this group when you don't follow the discussion. Jumping from file ulimits to data segment ulimits is really the move of a complete bonzo. It is possible to set the ulimit for a file without changing the maximum break. Try reading unlimit(2), that is if the brain still can handle reading. Now to address the issue. Generally speaking there is no need to change the system wide ulimit in the kernel for systems around System III, and given that ulimits weren't in Version 7, I think that covers all bases. The general trick is to create a version of getty that is a stub, or change your entris in /etc/inittab so that the ulimit setting routine is called before the real getty. Here is the code (totally untested) for the `execute the arguments after the program name' version. Real hard stuff ... An entry of the form 01:2:respawn:/etc/setulimit /etc/getty /dev/tty01 9600 in /etc/inittab should work just fine ... -- main (argcnt, argvec, envvec) int argcnt; char **argvec; char **envvec; { ulimit (2, 32000); /* 32000 blocks should do it ... */ execve (argvec[1], &argvec[1], envvec); exit (127); } -- Ain't that sweet ... - John. -- John F. Haugh II HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "Don't Have an Oil Well?" Dallas, TX. 75243 " ... Then Buy One!" (214) 231-0993
campbell@sauron.Columbia.NCR.COM (Mark Campbell) (10/04/87)
In article <29928@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: >> The default "ulimit" should be set using the default number of processes >> and the default amount of swap space. Careful use of "ulimit" allows one >> to avoid getting into pathological "out of swap space" conditions. > >Excuse me? How can the limit on the maximum FILE size - which is what is being >discussed here - have any direct effect on the consumption of swap space? Sorry...early Saturday morning knee jerk reaction. I had just finished battling some problems with "ulimit()" the night before -- basically a bug in the Perennial test suite which made some assumptions concerning the use of this system call in returning the maximum possible "brk()" value. This, coupled with a battle a few nights ago over another test suite which could only be fixed by lowering MAXUMEM and the V.3.1 change in name of ULIMIT to CDLIMIT, led to a truly strange interpretation of this message. -- Mark Campbell {}!ncsu!ncrcae!sauron!campbell
breck@aimt.UUCP (Robert Breckinridge Beatie) (10/07/87)
In article <29928@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > > [ comments that ulimit is used to prevent running out of swap] > > Excuse me? How can the limit on the maximum FILE size - which is what is being > discussed here - have any direct effect on the consumption of swap space? Actually, it's an understandable mistake. On many systems ulimit() can be used to find the maximum possible break value for the system. For example on Plexus system V systems, ulimit(3,0L) returns the maximum possible break value. It's not in the SVID but it is in enough implementations of unix that it's pretty confusing. Now for a question. As I said, ulimit can be used to find the maximum possible break value. But ulimit can't set the maximum possible break value. This seems a perfectly reasonable extension. Why can't the superuser change this value for his process? Does it complicate memory management too severely? -- Breck Beatie uunet!aimt!breck
steve@nuchat.UUCP (Steve Nuchia) (10/08/87)
In article <1731@killer.UUCP>, jfh@killer.UUCP (The Beach Bum) writes: > Here is the code (totally untested) for the `execute the arguments after > the program name' version. Real hard stuff ... An entry of the form You bet it's untested. Not a chance of it working on a stock Microbug system. > 01:2:respawn:/etc/setulimit /etc/getty /dev/tty01 9600 > > in /etc/inittab should work just fine ... [Nice, correct, useless little program deleted] Microport, in their infinite wisdom, has hooked up the kernel, init, and getty so that the snoop on each other and nothing will run if you substitute anything else for their getty. This is supposed to be to enforce the login-limit, which they do in getty. However, I've been told that even buying the unlimited liscense won't let you do this. Looks like I have some disassembly to do, since I am quite keen on hooking up an autobauding getty. Actually, I am writing a replacement for init that will be run from the main console by root instead of saying init 2. This is part of a research project, and is coming along nicely. (Aside: The sysV message queue mechanism lacks sender authentication, which I must consider a fatal flaw.) In the old days the liscense limit was enforced in the tty driver, which pissed off people who wanted to talk to serial peripherals. Then some vendors put it in login, which is a trivial program. Now microport has come up with a scheme that actually works. *sigh* -- Steve Nuchia | [...] but the machine would probably be allowed no mercy. uunet!nuchat!steve | In other words then, if a machine is expected to be (713) 334 6720 | infallible, it cannot be intelligent. - Alan Turing, 1947