New UUCP for A/UX?

[Richard Todd]

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

>Er, lighten up, please.  There is indeed a problem with uuxqt, and Glenn

Agreed.  I was rather rash in my reply, and I publically apologize to Glenn
for implying that he was an idiot. I jumped the gun and assumed that because
he said he was having permission problems with files, he actually *was*,
and I had also forgotten about the two bugs in UUCP which are worked around
or fixed on my system.  

However, his problem is not the (well-known) uuxqt bug, it looks like.  
For one thing, his original posting mentioned that the problem only occured
when uucico/uuxqt wasn't run when he was logged in as uucp; this obviously
can't be the problem with uuxqt running out of file descriptors, as this
would be independent of the environment that uuxqt is run from.  Also, I 
suspect Glenn would have noticed if it only happened when there were >13
entries in the queue.  

What the problem is is probably the one where uucico/uuxqt freaks if the TZ 
environment variable is not set.  This causes highly strange things to happen,
but not ones which "look" like permission problems.  (I just tried it with some
news batches waiting for the uuxqt, and got the error message along the lines
of "rnews failed (signal 0, exit 2)").  I didn't think of this at first, 
because a. I didn't remember ever seeing anything that looked like "permission
problems", and b. I fixed all my UUCP scripts to include TZ around April '89
and haven't had to think about it since.  

>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

Bingo! 

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

Yep, that's exactly it.

>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

Apple already knows about this bug; I got a fixed binary in the mail from
a guy at Apple after I yelled about it.  If enough of you will yell about it,
maybe they'll post the fixed binary to aux.support.apple.com.  It worked for
mkshlib, hey...

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

Given a 2400bps newsfeed, and roughly 50K newsbatches, even running uuxqt
every 30 minutes seems to be ok.  Note that if you, like me, have your 
system set up to run a poll every 30 minutes, uuxqt will run every 30 minutes
whether you want it to or not.  

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

Geez, people still run with /bin/rmail?  The first thing I did was toss the
entire rmail/sendmail system and install smail 2.5 and deliver.  Deliver seems
to be a lot more robust in its lock handling, and if you can get everyone on
your system to use a real Mail User Agent instead of mailx, you can use one
of the kernel locking protocols instead of the ".lock" kludge...

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

Well, it wasn't quite as seamless as all that.  The TZ problem I spotted right
off after an evening's hacking with it (simple detective work--if it works 
when run from your shell, but not from cron, what could be different between
the two?  Simple trial-and-error on environment variables did the rest).
If you wish to call that "talent", my ego won't mind...
As for the uuxqt-heavy-load problem, it simply didn't come up too often until
here recently (after a friend of mine downstream from me discovered these
wonderful new things called "mailing lists" :-), and by that point I'd already
gotten the new uuxqt.  So to summarize, it's not that everything was entirely
seamless, it's just that millions of my brain cells have died since then.
Still, UUCP and News require remarkably little attention; all I have to do
is occasionally fiddle the phone number in the L.sys file (alas, guessing which
of the 20 modems on my feed site are actually working on any given week is
often an adventure...) 
--
Richard Todd	rmtodd at uokmax.ecn.uoknor.edu  rmtodd at chinet.chi.il.us
	rmtodd at servalan.uucp
"Try looking in the Yellow Pages under 'Psychotics'." -- Michael Santana