Responses to my A/UX query for MacUser article

[Richard Todd]

domo at tsa.co.uk (Dominic Dunlop) writes:

>In article <10507 at panix.UUCP> alexis at panix.UUCP (Alexis Rosen) writes:
>> In particular, will the person who sent me that long article which mentioned
>> among other things the uuxqt bug (yes, i know _all_ about that one :-( )
That would be me, I think.  I'll dig out that email and send it again.
Alexis, if you don't get it this time, let me know and I'll post it; it's
probably of interest to the A/UX community in general.

>Aha!  This would be the bug whereby uuxqt gets bored with processing
>jobs after a while (around 20 jobs, but bafflingly variable) and either
>just gives up, or, if it's feeling more playful, fails to exec the
>commands for the last few batches, and sends mail back to their
>originators saying ``exit status 2'' or some such.  (Looks suspiciously
>like ``No such file or directory'' -- an outright lie -- to me, since I
>know that one of the commands in question, rnews, cannot exit with
>status 2, and I know that it's not being accessed when uuxqt starts to
>barf.)

The problem is that in uuxqt's main loop, where it processes each file, it
forgets to close one of the files.  Eventually it runs out of file handles,
can't open the work files, and aborts.  This in itself isn't too bad (it
just aborts and leaves the work files around for the next batch), but when
it's just one or two XQTs away from disaster, hence it's only got 1 or 2
free file handles; when rnews is forked off and runs, it only has 1 or 2 
file handles, and when it tries to do all those `spacefor`'s and stuff
(which require opening pipes, etc.) rnews fails in all sorts of entertaining
ways (usually coming to the erroneous conclusion that the disk is out of
space.)  I gather this bug is in a few other UUCP implementations besides
Apple's; at least, last time somebody asked on news.software.b why all
his news batches were being eaten on A/UX, Henry Spencer basically said, "Oh,
your uuxqt has the bug where ..."

>Anyway, how do you fix this sucker?  The bug, which was present in 1.1,
>seems to be bigger and better in 2.0.  (I even looked on Apple's Update
>and Information server for a fix.  No soap...)

First, you rob a bank.  Then, you use the $75,000 you got from robbing the 
bank to buy an AT&T source licence. :-).  

Seriously, *you* probably can't fix the bug.  You can, however, come
up with a workaround of sorts.  The problem is that rnews freaks out
when it can't open files and pipes because of too few file
descriptors.  A workaround is to move /bin/rnews to /bin/rnews.real and
compile the following and put in as /bin/rnews.
-------------------------Cut here----------------------------
/*
** Program to get around uuxqt's problem in not closing file descriptors--
** this is a front end to rnews that ensures that all fds from 3 up are 
** closed before the real rnews is executed.
*/
main() {
	int n=getdtablesize();
	int i;
	for (i = 3 ; i < n ; ++i) close(i);
	execl("/bin/sh","sh","/bin/rnews.real",(char *)0);
}
-------------------------Cut here------------------------------

Of course, when uuxqt itself runs out of file descriptors, it will fail,
but it seems to fail "cleanly", i.e. just leaving the remaining work files
around for the next uuxqt run.  

>Altogether now: I want my HDB!

Well, I'd settle for just a fixed version of uuxqt; having grown accustomed 
to old-UUCP, I really don't want to start learning about HDB's bugs....
--
Richard Todd	rmtodd at uokmax.ecn.uoknor.edu  rmtodd at chinet.chi.il.us
	rmtodd at servalan.uucp
Motorola Skates On Intel's Head!