news@ivucsb.UUCP (Todd Day) (11/13/88)
In article <2210005@acf3.NYU.EDU> rosenblg@acf3.NYU.EDU (Gary J. Rosenblum) writes:
_On another note, today I found a student running this wonderful
_little ditty, which he named oddly enough virus.c:
_
_main() { while (1) fork (); }
_
_and he effectively halted a small vax (11/750).
Isn't there something to prevent this sort of system crashing? It's
all too easy...steve@polyslo.CalPoly.EDU (Steve DeJarnett) (11/17/88)
In article <382@ivucsb.UUCP> news@ivucsb.UUCP (Todd Day) writes: >In article <2210005@acf3.NYU.EDU> rosenblg@acf3.NYU.EDU (Gary J. Rosenblum) writes: >_On another note, today I found a student running this wonderful >_little ditty, which he named oddly enough virus.c: >_ >_main() { while (1) fork (); } >_ >_and he effectively halted a small vax (11/750). > >Isn't there something to prevent this sort of system crashing? It's >all too easy... Well, we have this happen about one week out of every quarter. The faculty tell the students about fork() for some operating systems project or for networking (or some such thing), but they fail to tell them how to use fork properly (not that it's that difficult, but people manage to do what you mentioned above all the time). The only possible solutions we've found (short of removing fork() from the libraries) is to limit CPU usage (you can do this on BSD -- don't know about System V or other Unix variants). The problem you run into is people doing real work that need more CPU time than normal (maybe only for one quarter). Sure, you can change the allocation, but it's an overhead that we (and many other places, I'm sure) don't want/need. So, we make broad, sweeping threats in the hopes of getting people to check their code thoroughly before running it (but it does still happen). You can either put up with it (which is what we chose to do), or implement resource limits. Other than that, you're basically stuck. ------------------------------------------------------------------------------- | Steve DeJarnett | Smart Mailers -> steve@polyslo.CalPoly.EDU | | Computer Systems Lab | Dumb Mailers -> ..!ucbvax!voder!polyslo!steve | | Cal Poly State Univ. |------------------------------------------------| | San Luis Obispo, CA 93407 | BITNET = Because Idiots Type NETwork | -------------------------------------------------------------------------------
cbp@foster.avid.OZ (Cameron Paine) (12/05/88)
In article <2210005@acf3.NYU.EDU> rosenblg@acf3.NYU.EDU (Gary J. Rosenblum) tells us about dorks who write endlessly forking programs. In article <382@ivucsb.UUCP> news@ivucsb.UUCP (Todd Day) asks if there is a way this can be prevented. In article <5810@polyslo.CalPoly.EDU>, steve@polyslo.CalPoly.EDU (Steve DeJarnett) suggests placing limits on individual CPU usage. He (rightly) points out that this may unfairly restrict users doing real work. When I went to school, there was a quota system in place designed to prevent just this sort of malefaction (it prevented disk hogging too) on BSD systems. Regretably, I've no idea where the software came from. In the commercial world (under SV and its derivatives), I achieve this effect by careful tuning of the MAXPROC and MAXUP parameters. The former establishes a ceiling on total concurrent processes; the latter does the same on a per-user basis. On all the machines we manage, MAXUP falls in the range 20 - 30 and MAXPROC is determined by: MAXPROC = MAXUP * available_login_ports + number_of_system_processes; These two parameters are given different names by different kernels. They are usually set in config.h (though many vendors provide cute front-ends to avoid editing this file). cbp -- cbp@foster.avid.oz - {ACS,CS}net cbp%foster.oz.au@uunet.uu.net - ARPAnet ...!{hplabs,mcvax,nttlab,ukc,uunet}!munnari!foster.oz.au!cbp - UUCP D
guy@auspex.UUCP (Guy Harris) (12/07/88)
>When I went to school, there was a quota system in place designed to prevent >just this sort of malefaction (it prevented disk hogging too) on BSD systems. >Regretably, I've no idea where the software came from. It may have come from Melbourne; the BSD disc quota stuff was adopted from the Melbourne quota mechanism. >In the commercial world (under SV and its derivatives), I achieve this effect >by careful tuning of the MAXPROC and MAXUP parameters. The former >establishes a ceiling on total concurrent processes; the latter does >the same on a per-user basis. Those limits date back to V7, and are thus also in systems that started from BSD. (The parameters may have different names.)