jc@minya.UUCP (jc) (10/05/87)
> >As for the original problem, can't superuser set the ligit up as > >well as down? > > That IS the original problem! ONLY the super-user can get around > the ridiculously small initial ulimit coded into the kernel! OK, I decided to see how hard this one was; it took 15 minutes, of which 13 were due to a bug in init.... What you do is change your inittab entries for getty to: t3:2:respawn:/bin/sh /etc/Getty tty03 tty03 The /etc/Getty script looks like: ulimit 8000 # or whatever you like. exec /etc/getty $* The bug in init is that the "/bin/sh " is required; init refused to run a shell script directly. [Grumble; the toikeys; grumble; wasting 13 minutes of my time; grumble; had to go to 2nd terminal to recover when the first one went zombie; grumble... :-] There, wasn't that easy? -- John Chambers <{adelie,ima,maynard}!minya!{jc,root}> (617/484-6393)
jal@oliveb.UUCP (Benjamin G. Golding) (10/06/87)
In article <275@minya.UUCP>, jc@minya.UUCP (jc) writes: > OK, I decided to see how hard this one was; it took 15 minutes, of which > 13 were due to a bug in init.... > > What you do is change your inittab entries for getty to: > > t3:2:respawn:/bin/sh /etc/Getty tty03 tty03 No. This does not alter the ulimit for processes like cron and the jobs that it starts up. This really is terribly broken and a major oversight by AT+T. I have had trouble with this in a numer of different ways, such as accidentally setting it to -1 and not being able to login because /etc/login can't write /etc/utmp! Can you believe they made it signed?! At least it's configurable in rel 3.1, though silly that you can't turn it off. Ben Golding. -- "Holy oleo, Batman!!" "Why Boy Wonder; I didn't know you could yodel!"
rjd@tiger.UUCP (10/08/87)
> > OK, I decided to see how hard this one was; it took 15 minutes, of which > > 13 were due to a bug in init.... > > > > What you do is change your inittab entries for getty to: > > > > t3:2:respawn:/bin/sh /etc/Getty tty03 tty03 That is not a bug. Its a feature!!! :-) Seriously, init was not meant to start up shell scripts.... If you want to raise the ulimit for login sessions, GET THE SOURCE to /bin/login and put the ulimit call in there before it setuid's and execs the shell. It takes about 90 seconds to find, a minute or so to compile, and a few keystrokes to overwrite the original login (a few more if you want to save the original login). > No. This does not alter the ulimit for processes like cron and the > jobs that it starts up. It was not meant to, the original question was inquiring about raising the ulimit for logins. > This really is terribly broken and a major oversight by AT+T. I have > had trouble with this in a numer of different ways, such as > accidentally setting it to -1 and not being able to login because > /etc/login can't write /etc/utmp! Can you believe they made it > signed?! At least it's configurable in rel 3.1, though silly that you > can't turn it off. > > Ben Golding. If you want the ulimit upped for cron and other deamons started on bootup, and it is not already (I do not know that it is not already high), just put the ulimit <high number> in the shell script in /etc/rc.d/cron (release 2 unix) or /etc/rc2.d/S??cron (for release 3). You can start it less selectively by just putting the high ulimit in the /etc/rc2 shell script, if you like.... "terribly broken and a major oversight"???? Sorry, I bet they did not know that you had an INFINITE amount of space available and were not concerned with limiting it. Since I bet somehow that you do not have an infinite space, you probably DO need a limiter. You setting it to -1 proves the fact that you are not infallible and might screw up again!!! It is really so simple: root can raise the ulimit for himself and all child processes to anything he wants, non-roots can only lower it. If you want to lower it for some people and raise to for others, either do the mod that Mike Manitus posted that allows you to set up the param- aters in the /etc/passwd file, or simply change login for the higher ulimit and have /etc/profile lower it on a user-by-user basis (note: logins that do not run a shell, such as nuucp running uucicio, will not get the ulimit lowered). Randy
guy%gorodish@Sun.COM (Guy Harris) (10/10/87)
> That is not a bug. Its a feature!!! :-) Seriously, init was not > meant to start up shell scripts.... What? This is nonsense. Note the following line, from the S5R2 "inittab": rc::wait:/etc/rc 1>/dev/console 2>&1 #run com "/etc/rc" sure looks like a shell script to me.... > If you want to raise the ulimit for login sessions, GET THE SOURCE to > /bin/login and put the ulimit call in there before it setuid's and execs > the shell. Give me a break. Most people these days don't *have* the source to UNIX, and most of them have better things to do with what could be up to $53,000. Saying "you can fix this by tweaking the source" may be useful for some people as a workaround, but it hardly indicates that there's nothing wrong. > "terribly broken and a major oversight"???? Sorry, I bet they did not > know that you had an INFINITE amount of space available and were not > concerned with limiting it. Since I bet somehow that you do not have > an infinite space, you probably DO need a limiter. You setting it to > -1 proves the fact that you are not infallible and might screw up again!!! More nonsense. First of all, there are many sites that have *sufficient* disk space that a per-file disk space limit is not useful; many of those sites are running applications that want to handle large files, and don't want to have to cook up some kludge to run those applications with a sane file size limit. Second of all, a file size limit is certainly not the ONLY way to control disk space usage - unless, of course, you're stuck with an OS that doesn't offer e.g. per-user disk quotas. Many UNIX users *do* have systems that support disk quotas. Disk quotas more deal more directly with the problem, by giving a user a certain number of disk blocks, and leaving it up to *them* to choose how to use them; if they have 10MB, and want an 8MB file and a bunch of small files, they can do so. Face it: many, many people have complained about 1MB ulimits. Many, many real live sites find it to interfere with their ability to use the system. It's just a damn shame that the default ulimit wasn't made a tunable parameter until System V Release 3.1; fortunately, there are plenty of systems out there that don't stick you with this, and many of them even give you disk quotas to provide different and, in many ways, better ways of solving the problem. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
emigh@ncsugn.ncsu.edu (Ted H. Emigh) (10/12/87)
In article <275@minya.UUCP> jc@minya.UUCP (jc) writes: >> >As for the original problem, can't superuser set the ligit up as >> >well as down? >> >> That IS the original problem! ONLY the super-user can get around >> the ridiculously small initial ulimit coded into the kernel! > >What you do is change your inittab entries for getty to: > > t3:2:respawn:/bin/sh /etc/Getty tty03 tty03 > >The /etc/Getty script looks like: > > ulimit 8000 # or whatever you like. > exec /etc/getty $* > ncsugn has been using the following program for some 5 months -- the original came from the net from some person at AT&T. ncsugn is a 3B2/400 running SVR3.0. /* Change the file size limit Compile this and put it in place of the usual init program: cc ulimit.init.c -o ulimit.init mv /etc/init /etc/real.init mv ulimit.init /etc/init chmod 754 /etc/init <-- Same as the old init The next time the machine is booted, the ulimit will be changed. */ main(argc, argv) int argc; char *argv[]; { ulimit(2, 32768L); /* "2" sets ulimit. 32768 = 16Mb. */ execv("/etc/real.init", argv); } -------------------- -- Ted H. Emigh, Dept. Genetics and Statistics, NCSU, Raleigh, NC uucp: mcnc!ncsuvx!ncsugn!emigh internet: emigh%ncsugn.ncsu.edu BITNET: NEMIGH@TUCC @ncsuvx.ncsu.edu:emigh@ncsugn.ncsu.edu
tel@moby.UUCP (Tom Lowe) (10/12/87)
In article <6497@oliveb.UUCP>, jal@oliveb.UUCP (Benjamin G. Golding) writes: > In article <275@minya.UUCP>, jc@minya.UUCP (jc) writes: > > OK, I decided to see how hard this one was; it took 15 minutes, of which > > 13 were due to a bug in init.... > > > > What you do is change your inittab entries for getty to: > > > > t3:2:respawn:/bin/sh /etc/Getty tty03 tty03 > > No. This does not alter the ulimit for processes like cron and the > jobs that it starts up. > Very true unfortunately....... Workaround: in /etc/rc.d/cron add the line 'ulimit 40960' or whatever number before the line '/etc/cron' This same thing works for any shell script in rc.d that needs a larger ulimit. For people who don't know what /etc/rc.d is, that's is a directory that contains shell scripts that are executed every time the system is taking to init run level 2 (look in /etc/rc2 to see how this is done). -- Tom Lowe {rutgers,gatech,huscb,burdvax,ihnp4,cbosgd}!psuvax1!moby!tel AT&T National Systems Support Center, S. Plainfield, NJ (1-800-922-0354) Please call only if you have an AT&T computer under Warranty or if you have an AT&T Maintenance Contract on your equipment.
bzs@bu-cs.bu.EDU (Barry Shein) (10/16/87)
>If you want to raise the ulimit for >login sessions, GET THE SOURCE to /bin/login and put the ulimit call >in there before it setuid's and execs the shell. ... > "terribly broken and a major oversight"???? Sorry, I bet they did not >know that you had an INFINITE amount of space available and were not >concerned with limiting it. Since I bet somehow that you do not have >an infinite space, you probably DO need a limiter. You setting it to >-1 proves the fact that you are not infallible and might screw up again!!! You must have worked for the VMS group in a previous life (it can't be wrong, that's the way we implemented it!) What's wrong and terribly broken is not that the feature exists, it's that you can't set it to a value reasonable for your site without the source (or various wizardry.) All by itself it can cripple a system's useability. Actually, ulimit is completely broken anyhow, see BSD's disk quota system for the kind of thing adults implement. This is not a BSD v SYSV thing, a disk quota system would fit just fine into SYSV without interfering with their precious SVID. We can't even consider SYSV without a rational disk quota system (would you like to manage a 15,000 user system, mostly students, without something better than ulimit and the hacks you suggest above?) I believe SYSV is about the only O/S people are actually selling for money these days without some sort of disk quota system, I may be wrong, but be careful who you name as your equivalents. How hard could it be to manage four integers? It boggles the mind. I think you're acting as an unneeded apologist for an obvious deficiency. -Barry Shein, Boston University
olapw@olgb1.oliv.co.uk (Tony Walton) (10/23/87)
In article <9807@brl-adm.ARPA>, bzs@bu-cs.bu.EDU (Barry Shein) writes: > > >If you want to raise the ulimit for > >login sessions, GET THE SOURCE to /bin/login and put the ulimit call > >in there before it setuid's and execs the shell. There is a simple fix which we distribute to our VARs. It consists of the binary of /*******************************************************/ main(argc, argv) int argc; char **argv; { ulimit(2,10000L); setuid(getuid()); setgid(getgid()); execvp(argv[1], &argv[1]); } /*******************************************************/ The binary is owned by root, is chmod 4555, and lives in /usr/bin/fixulimit. It allows a *single* command to be run with the increased ulimit. Then add exec fixulimit /bin/sh to the .profile of any user that needs it. OK, it's a nasty kludge (kluge?), but it works and doesn't need recompilation of login.c Of course, ULIMIT is tunable in SVR3.1......
jfh@killer.UUCP (The Beach Bum) (10/26/87)
In article <259@olgb1.oliv.co.uk>, olapw@olgb1.oliv.co.uk (Tony Walton) writes: > In article <9807@brl-adm.ARPA>, bzs@bu-cs.bu.EDU (Barry Shein) writes: > > > > >If you want to raise the ulimit for > > >login sessions, GET THE SOURCE to /bin/login and put the ulimit call > > >in there before it setuid's and execs the shell. [ And one day, we'll all have the source to everything. Wouldn't that be nice? ] > There is a simple fix which we distribute to our VARs. It consists of the > binary of > > /*******************************************************/ > > main(argc, argv) > int argc; > char **argv; > { > ulimit(2,10000L); > setuid(getuid()); > setgid(getgid()); > execvp(argv[1], &argv[1]); > } > [ suggestion about a setuid-root program deleted. why not just fix it for good? ] > Of course, ULIMIT is tunable in SVR3.1...... Or, you change /etc/inittab so that /etc/setulimit or whatever is called before /etc/getty. Try: 01:2:respawn:/etc/setulimit /etc/getty /dev/tty1 9600 instead of whatever you had (you do need to change the id and device entries though ...) An alternative, is to look for the parameter in /usr/include/sys/var.h that sets the default ULIMIT (I think its CDLIMIT this week) and patch that word in the kernel file, and reboot. (You must reboot unless you want to patch /etc/init's U-page.) - 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