Return to BSD News archive
Newsgroups: comp.unix.bsd.freebsd.misc Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!uwm.edu!spool.mu.edu!bloom-beacon.mit.edu!gatech!news.sprintlink.net!news.cyberenet.net!twwells!bill From: bill@twwells.com (T. William Wells) Subject: Re: Zombie processes eating up CPU time (was Re: Internet Service Provider) Organization: None, Mt. Laurel, NJ Message-ID: <D941A5.659@twwells.com> References: <3pqb92$lq2@pt9201.ped.pto.ford.com> <3prh5v$au8@fnord.dfw.net> <D91uu8.7J3@twwells.com> <3pub0e$ppd@gate.sinica.edu.tw> Date: Thu, 25 May 1995 01:25:16 GMT Lines: 47 In article <3pub0e$ppd@gate.sinica.edu.tw>, Brian Tao <taob@gate.sinica.edu.tw> wrote: : In article <D91uu8.7J3@twwells.com>, T. William Wells <bill@twwells.com> wrote: : >The biggest problem with FreeBSD (2.0) that I've seen so far is : >that when connections are just "dropped" many programs go into an : >infinite read loop. I need to figure out where that's coming from : >and *fix* it, as it eats CPU time. : > : >BTW, at one time, BSDI had the same problem. Might still. : : I don't think this is as much an OS-related problem as a program : application problem. When an OS change results in a dozen applications all breaking the same way, it's an OS problem. : For example, on my ISP (which runs BSD/OS 2.0), : the most commonly seen "hung" processes are Lynx 2.3, Pine and tin. : All three poll the tty for keyboard input from the user. In fact, most programs that poll for input are likely to be affected. There has been some fundamental change in the way that later BSD's have dealt with disconnects. Hopefully, somebody who *knows* will say and save me the trouble of tracking it down. : frenzy looking for input data. The incessant looping drives the : program to hog almost all the CPU, to the detriment of other : interactive programs. Like, duh. I know all this. : Our solution: give every user a CPU quota. *You* give every user a CPU quota. *I* am not in the business of putting limits on my customers just because I am using defective software. : See the man page on : csh/tcsh for the built-in "limit" command, and the man pages for : getrlimit(2) and setrlimit(2). Do you know how fatuous you sound to a guy who has been programming and administering Unix systems for twelve years? Please don't waste my time with the obvious. This is a problem that needs to be *fixed*, by fixing the OS, not by piecemeal hacks on applications, or bandaids added to the various shells.