*BSD News Article 44567


Return to BSD News archive

Newsgroups: comp.unix.bsd.freebsd.misc
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.uwa.edu.au!classic.iinet.com.au!news.uoknor.edu!news.ecn.uoknor.edu!news.ysu.edu!usenet.ins.cwru.edu!agate!howland.reston.ans.net!swrinde!emory!news-feed-1.peachnet.edu!usenet.eel.ufl.edu!news.mathworks.com!solaris.cc.vt.edu!spcuna!ritz!ritz
From: ritz@ritz.mordor.com (Chris Mauritz)
Subject: Re: Zombie processes eating up CPU time (was Re: Internet Service Provider)
References: <3pqb92$lq2@pt9201.ped.pto.ford.com> <3prh5v$au8@fnord.dfw.net> <D91uu8.7J3@twwells.com> <3pub0e$ppd@gate.sinica.edu.tw>
Organization: Mordor International
Date: Wed, 24 May 1995 05:58:18 GMT
X-Newsreader: TIN [version 1.2 PL2]
Message-ID: <D92J96.AMH@ritz.mordor.com>
Lines: 48

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.

Still does.

:     I don't think this is as much an OS-related problem as a program
: application 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.

Tin is the biggest culprit here as it is an incredible resource
pig to begin with.  The latest version of elm2.4 also exhibits
the behavior.

: All three poll the tty for keyboard input from the user.  When the
: user disappears of his end of the connection, the program goes into a
: frenzy looking for input data.  The incessant looping drives the
: program to hog almost all the CPU, to the detriment of other
: interactive programs.  At least this problem is solved in recent
: versions of Lynx.

I've wondered why they don't just implement some sort of counter
in the loop to kill the process if it's obviously looping out of
control.

:     Our solution:  give every user a CPU quota.  See the man page on
: csh/tcsh for the built-in "limit" command, and the man pages for
: getrlimit(2) and setrlimit(2).  Each user is allowed 10 minutes of CPU
: time per process.  Any single process exceeding this amount is killed

This is exactly what I've done.  It's not a great solution, as a
couple of loopers can bog the machine for quite a while before
they get killed.

Regards,

Chris
-- 
Christopher Mauritz         | For info on internet access:
ritz@mordor.com             | finger/mail info@ritz.mordor.com OR
Mordor International        | http://www.mordor.com/
201/212/718 internet access | Modem: (201)433-7343,(212)843-3451