uuxqt. The Mother of Invention. Fixed, at last.

[Richard Michael Todd]

(Note: The following article contains a description of the uuxqt bug that I
took out of a news article I posted a couple of days ago.  The reason I'm
reposting this is because none of you got to see this the first time,
because the article has been waiting for *3 DAYS* in uokmax's inbound spool
directory waiting for uuxqt to do something with it.  Looks like Apple's
not the only one with uuxqt problems.  You'll probably see the guts of this
message again if and when uuxqt on uokmax gets a clue and actually starts
executing requests again.  Tough.  I don't suppose Apple has any plans to
port A/UX to the Multimax; it'd be a distinct improvement on what we've
already got...)

Anyway,

alexis at panix.uucp (Alexis Rosen) writes:
>I and several others have in recent weeks complained about uuxqt's habit
>of quitting in the middle of a large job. This was annoying, but I thought
>I'd solved it by running it from cron every half hour. This is *DEFINITELY*
>not the answer though- it will still toast your files fairly frequently. Of
>course, I didn't find this out until Cnews had the grace to tell me there
>was a problem.

Actually, the problem is that rnews will toast the batch it's receiving 
when it's executed with only one free file descriptor.  See below.

>Since Apple obviously can't write a working uucp (excepting Ron, who's not
 Actually, I seriously doubt Apple had anything to do with this one.  I 
gather other versions of uuxqt have had this problem; the bug is probably
a leftover from AT&T.  

 Anyway, here's the explanation of the uuxqt bug, along with another
workaround: 

 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 ..."

Dominic Dunlop asks: 
>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....

Anyway, back to Alexis' article: 
>The strategy is simple. uuxqt never dies quickly- it must go through (it
>seems, from watching many runs) at least 15 or 18 X files before it has a
>chance to die. So I never give it a chance to die. I simply hide the X
>files, and show them 10 at a time. I'm not sure but I think this may actually
>speed up uuxqt if there's a lot of files in the spool (like, more than 300).
>I also do some locking that is, as far as I can tell, 100% safe.

The number of X. files uuxqt gets a chance to run through depends on how
many free file descriptors it had when it started, which depends somewhat
on how it was executed.  

>If anyone discovers any bugs, please mail to me as well as posting. After
>all, if it is broken (unlikely though I think that to be), my news won't
>be all that reliable...

  Since mail and news are both handled by uuxqt, the two should be about
the same in terms of reliability.  (Granted, rnews fails if it's just very
low on file descriptors, but I suspect any halfway complicated MTA like
smail or sendmail will also fail under such conditions.)

  Given the description of the problem, it shouldn't be too difficult for
someone at Apple to fix this bug.  Any takers?  Ron?  You listening?  
-- 
Richard Todd   rmtodd at chinet.chi.il.us  or  rmtodd at uokmax.ecn.uoknor.edu