Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!yale!hsdndev!cmcl2!panix!alexis
From: alexis@panix.uucp (Alexis Rosen)
Newsgroups: news.software.b
Subject: Re: C news problem:  spacefor script
Message-ID: <1991Mar10.204709.10460@panix.uucp>
Date: 10 Mar 91 20:47:09 GMT
References: <1991Mar6.153527.10070@casbah.acns.nwu.edu>
Organization: PANIX - Public Access Unix Systems of NY
Lines: 110

phil@eecs.nwu.edu (William LeFebvre) writes:
>We are running C news on an Encore Multimax running UMAX 4.3 (release 4.0).
>
>Some times, but not all the time, when uuxqt runs rnews on an incoming batch,
>the script "spacefor" as invoked by rnews does not write anything to
>standard output.  As a result, the check for free space fails and the
>batch is (eventually) dropped.  Once spacefor starts doing this, it continues
>to happen until I modify rnews or otherwise interfere with the goings on.
>
>I have not been able to get spacefor to fail by invoking it myself.  I
>have not been able to get things to fail by invoking uuxqt by hand.
>
>Has anyone seen this?  Can anyone lend some advice?

Henry Spencer suggests, in a followup message, that some old uuxqt's were
sloppy about closing files. This is the case with A/UX, and (after months
of headscratching) when I finally came up with a workaround, Richard Todd
mentioned in a followup posting that MultiMaxes had this problem too.

If your uucp load is low, you can get away with running uuxqt every few minutes
while a uucico is running. This will prevent the buildup of incoming jobs
that leads to uuxqt failing. The better solution is to use the script I'm
including at the end of this message.

A few notes:
1) This script or something like it probably belongs in Cnews' contrib
directory. There are a lot of ancient doddering UUCPs out there!
2) Kudos to Henry and Geoff. We had this problem for months before we even
realized it. Mail and news was vanishing without a trace, and we never knew.
Then we installed Cnews, and started getting error messages. Their paranoid
programming helped us tremendously.
3) You're also losing mail, just like we did.
4) This problem is fixed in A/UX 2.0.1. (so you can throw out the multimax
and get a Mac IIfx :-))

To use the uuxqt.wrap script, rename your uuxqt to uuxqt.real. Then install
this uuxqt.wrap in /usr/lib/uucp (or the corresponding directory on your
system) with the same protections as uuxqt.real. You may need to revise the
script a bit if you have an old or broken Bourne shell. In particular you may
need to replace the square brackets in the ifs with "test"s. You should check
to make sure that all file and directory names are appropriate for your system.

The busier your system, the fewer jobs each invocation of uuxqt should see.
I run a fairly busy site with as many as three uucicos going on at once, so
I allow seven X files at a time. If you never have more than one connection
at a time ten is safe. Basically, the problem is that ten is always safe, but
if you have several simultaneous connections, you can accumulate a bunch of
new X files while a uuxqt is running, bringing it over the ten job limit. Once
you start hitting the Cnews errors, you're hosed. The uuxqt won't go away
until it chews up fifteen more jobs or so, at which point it dies entirely.

Anyway, use and enjoy.
---
Alexis Rosen
Owner/Sysadmin, PANIX Public Access Unix, NY
{cmcl2,apple}!panix!alexis
For brain dead mailers which can't send to uucp sites: rosen@nyu.edu

---------------------------->% cut here %<--------------------------------
#!/bin/sh
# uuxqt.wrap - V1.0 written by Alexis Rosen 9-30-90
# This bourne shell script is a wrapper for uuxqt which will prevent it from
# crapping out in the middle of a long run, almost certainly losing a file
# in the process. Rename the original uuxqt to uuxqt.real and change this
# file's name to uuxqt. This should be ownned/group by uucp, mode 770.
# Bugs or comments to panix!alexis or alexis@panix.uucp or rosen@nyu.edu

# modified 12/11/90 by Alexis to do only seven files per XQT

cd /usr/spool/uucp
if [ ! -f X.* ] ; then exit 0 ; fi		# nothing to do

HIDEDIR=/usr/spool/uucp/hidden-x-files		# stick excess X files here

if [ ! -d $HIDEDIR ] ; then mkdir $HIDEDIR ; chmod 770 $HIDEDIR ; fi

# check for a LCK.WXQT file. If it exists, see if it's stale or not.
# There is a very small window of time in which this locking system could
# fail. So wait ten seconds (probably way conservative) and inspect the lock.
if [ -f LCK.WXQT ] ; then
	kill -0 `cat LCK.WXQT` 2>/dev/null
	if [ $? != 0 ] ; then		# stale lock
		rm -f LCK.WXQT
	else
		exit 0
	fi
fi
trap 'rm -f LCK.WXQT /tmp/xw$$' 0 1 2 15
echo "$$" >LCK.WXQT			# make the lock

# Check the lock to make sure we kept it. If not let the other guy do the work.
sleep 10
if [ $$ != `cat LCK.WXQT` ] ; then trap 0 1 2 15 ; exit 0 ; fi

# Now move all the X. files into the hidden directory and then move 10 back
# out. When there aren't many X. files this won't matter but when there are
# hundreds, it's much more efficient than moving all but 10. Put the mv inside
# the loop to pick up any new X. files that might have just arrived.
while : ; do
	mv -f X.* $HIDEDIR 2>/dev/null	# all X. files into the hole
	ls $HIDEDIR >/tmp/xw$$		# make a list
	for i in `head -7 /tmp/xw$$` ; do	# pull out first bunch
		mv $HIDEDIR/$i $i
	done
	if [ ! -f X.* ] ; then exit 0 ; fi		# normal exit here

	/usr/lib/uucp/uuxqt.real $*	# fire up the real uuxqt
	XEXIT=$?
	if [ $XEXIT != 0 ] ; then exit $XEXIT ; fi
done