Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!mips!sgi!shinobu!odin!sgihub!dragon!bananapc.wpd.sgi.com!ciemo
From: ciemo@bananapc.wpd.sgi.com (Dave Ciemiewicz)
Newsgroups: comp.sys.sgi
Subject: Re: Brain-dead jobs hangin' around, and other grusome subjects...
Message-ID: <1990Nov13.180238.3222@relay.wpd.sgi.com>
Date: 13 Nov 90 18:02:38 GMT
References: <1990Nov12.145601.23556@cunixf.cc.columbia.edu>
Sender: news@relay.wpd.sgi.com ( CNews Account )
Reply-To: ciemo@bananapc.wpd.sgi.com (Dave Ciemiewicz)
Organization: sgi
Lines: 24

In article <1990Nov12.145601.23556@cunixf.cc.columbia.edu>, shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) writes:
|> 
|> Occasional invocations of "ps -ef" on a Personal Iris (25TG) running
|> 3.2.1 have revealed dead jobs haunting the system.  Most of these
|> seem to be residues of running the "man" command, often several days/
|> logins ago.  Since man sets up a pipe, each invocation that hangs around
|> keeps three or four jobs on the list;  however, this does not happen for
|> every invocation of "man".  Does anyone out there have an idea how this 
|> can be prevented?
|> 

There was a race condition in the 3.2 man command itself with respect to the
shell.  When 3.2 man is interrupted using ^C aka ctrl-C (or whatever your
interrupt character is set to), 3.2 man does not properly wait on its
children thus the orphans.

This bug is fixed in the 3.3 software release.  The solution is to upgrade
your release.  The interrim solution is to train yourself not to quit viewing
a man page by typing ^C but instead to press "q" to quit more(1) from paging
anymore of your man page.  As you noted, interrupting 3.2 man with ^C won't
always cause this, only sometimes which made the race condition elusive to
find.

						--- Ciemo