From Ucbosgd Thu Jan 31 20:19 CST 1985
>From hou3c.UUCP!ka  Thu Jan 31 18:33:54 1985 remote from cbosgd
Date: Thu, 31 Jan 85 18:33:54 est
From: cbosgd!hou3c.UUCP!ka
Message-Id: <8501312333.AA04493@cbosgd.ATT.UUCP>
Received: by cbosgd.ATT.UUCP (4.12/3.7)
	id AA04493; Thu, 31 Jan 85 18:33:54 est
Sent-By: hou3c.UUCP Thu Jan 31 16:31 EST 1985
To: ihnp4!gatech!spaf
Subject: Re:  Why can't uucp transfer news articles from where they sit?
Cc: cbosgd!plus5!hokey
Status: RO

	From: ihnp4!gatech!spaf
	Date:     29 Jan 85 20:53:04-EST (Tue)
	Original-From:     Gene "6 months and counting" Spafford <spaf@gatech>
	To: Plus5!hokey
	Cc: seismo!rick, hou3c!ka
	Subject:  Re:  Why can't uucp transfer news articles from where they sit?
	Message-Id: <850129.2045.12966.0@GaTech>
	
	There is a known bug in xfernews though.  If you start up a second xfernews
	while one is still running (say after an hour or so) the second one
	complains that the first one didn't remove the lock.  It then removes the
	lock and continues on its merry way!  The first instance of xfernews
	then runs into various difficulties, including losing its sense of
	current directory, and generates lots of error messages before dying.
	We have resolved that by only running xfernews every 2 or 3 hours.

	--gene

I expect I know what that is.  If you look at the macro procexists
in common.h, you will notice that it sends a signal zero to check
for process existence.  This is an old feature of the signal routine,
but it wasn't documented until System III, so that it may not appear
in BSD.  The solution is to use a real signal (such as SIGHUP) and
have recvnews ignore that signal.
				Kenneth Almquist


