New UUCP for A/UX?

[Dominic Dunlop]

austin at spies.sf-bay.org (Glenn Austin) writes:
> 
1> I have attempted to use the UUCP which came with A/UX 2.0, and it works fine
1> when logged in as UUCP, but fails (miserably!) when running in the background
1> because UUCICO doesn't correctly handle the options for files transferred.
1> It creates all files as mode 600, and then when UUX attempts to read them
1> (ie. to send mail)...
> 
And in article <1991Feb4.045449.29142 at servalan.uucp> rmtodd at servalan.uucp
(Richard Todd) expresses the sentiment:
2> [As I don't have a problem, you can't have a a problem or you have done
2> something unspeakably dumb.]

Er, lighten up, please.  There is indeed a problem with uuxqt, and Glenn
seems to be on its track -- even if he has not quite chased it
down.  The problem is that, when more than <some number less than 20>
jobs are queued up for uuxqt to run, uuxqt runs out of file descriptors
before it has processed them all.  Presumably, there is some loop
inside uuxqt which it cycles round for each job, and at the end of
which it should be closing all open files -- but doesn't.  This bug can
present with a number of symptoms.  Sometimes it seems that uuxqt
itself is failing -- for example, not being able to read files.
Sometimes, the child process executed by uuxqt to do the work
(typically rmail or rnews) runs out of file descriptors first, because
uuxqt has passed it a load of useless open files, and the child does
not close them before it tries to open others.

Firstly, Apple, can we please have a fix for this long-standing problem?
You have, after all, posted fixes for bugs in a (small) number of other
utilities to ``A/UX Update and Information Server'' (uucp access on +1
408 559 3066 -- login as aux; annonymous ftp also available on
aux.support.apple.com (130.43.6.2)).

Secondly, what can Glenn do about it?  Well, there has been a fair amount
of discussion in this newsgroup -- the archives for which are on the
A/UX Update and Information Server.  I've found that changing the body of
/usr/lib/uucp/uushell -- the shell that gets executed when nuucp logs in
-- helps:

while :; do sleep 300; /usr/lib/uucp/uuxqt; done &
env "TZ=`/bin/cat /etc/TIMEZONE`" /usr/lib/uucp/uucico

This works for me because my particular problem is in the processing of
large incoming news batches.  Having uuxqt run every five minutes while
nuucp is logged in means that too few to cause a problem are queued at
at any time.  It may not work for you, though.

I seem to recall that there's also a problem with /bin/rmail.  As
delivered, it's setuid root.  It should be setgid mail instead.  If it's
setuid root, multiple copies of rmail running simultaneously can
overwrite each others' additions to mailboxes because root privilege
breaks the locking mechanism that they use serialize their access.  The
symptom is corrupted mailboxes whenever multiple messages arrive
at the same time for the same user.  Could be that this classic UniSoft
problem is fixed in A/UX 2.0; I don't remember.

2> I've been running UUCP [without problems] on my 
2> A/UX machine since April of 1989, have been running news on it since June of
2> 1989, and have been feeding news to other sites and gatewaying mail in and 
2> out of central Oklahoma since mid-summer 1990...

Well, I'm surprised that you've had no problems.  Wish I had your luck
(or talent).
-- 
Dominic Dunlop