Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!munnari!bruce!labtam!foster!cbp From: cbp@foster.avid.OZ (Cameron Paine) Newsgroups: news.sysadmin Subject: Re: Outrageous amount of multiple forks Summary: Could you not lower your process ceiling? Message-ID: <158@foster.avid.OZ> Date: 5 Dec 88 00:29:18 GMT References: <22401@cornell.UUCP> <2210005@acf3.NYU.EDU> <382@ivucsb.UUCP> <5810@polyslo.CalPoly.EDU> Organization: Avid Systems Pty Ltd, Australia Lines: 34 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