alexis@panix.uucp (Alexis Rosen) (12/14/90)
For those who have been following the saga of panix's uucp woes, the score is:
A/UX UUCP - 3 panix - 0
at the end of the first half. But now, we begin to make a comeback...
In my postings yesterday I described how I discovered what appears to be a
nasty bug (or misconfiguration) of mail. I had also said that news was
misbehaving, but that that wasn't related to our mail problem.
The problem with news is that uuxqt is broken, and it causes news to be
dropped on the floor. Other types of xqts could also break. Two months
ago I posted a shell script, uuxqt.wrap, that made uuxqt safe to use and
it worked like a champ for two months.
Last week, the wrapper started failing accasionally. I eventually discovered
that since we were now calling several sites simultaneously, uuxqt could be
set off while a uucp connection was in progress. Thus the wrapper, which
tries to keep uuxqt from doing more than ten jobs before exiting, was actually
letting anywhere from 10 to 13 or 14 jobs get to uuxqt. Unforunately, if the
eleventh is a news job (or at least a Cnews job), it will fail. By the time it
recovers (after tossing the newsbatch), many more jobs will have arrived, and
it will continue to kill newsbatches until the uuxqt expires completely.
Fortunately, the fix is simple (if a bit inefficient). Simply change the line
in uuxqt.wrapper (which should be in /usr/lib/uucp/uuxqt if you're using it)
from
for i in `head /tmp/xw$$` ; do # pull out first ten
to
for i in `head -7 /tmp/xw$$` ; do # pull out first seven
...and that's all it takes. If you're paranoid or you get many simultaneous
connections transferring small files, you might cut it as low as five.
This fix has been in place for several days and it has proven impervious
to heavy simultaneous uucp traffic.
I hope that everyone finds this info useful. At this point we're only lacking
a patch to mail (as described yesterday). I know I said I'd try to patch it
myself if nobody else does, but I thought of a fairly easy way to do it with
another shell-script wrapper. I'd still prefer a patch, though, as it's much
more efficient. Anybody offering?
---
Alexis Rosen
Owner/Sysadmin, PANIX Public Access Unix, NY
{cmcl2,apple}!panix!alexisrmtodd@servalan.uucp (Richard Todd) (12/15/90)
alexis@panix.uucp (Alexis Rosen) writes: >I hope that everyone finds this info useful. At this point we're only lacking >a patch to mail (as described yesterday). I know I said I'd try to patch it >myself if nobody else does, but I thought of a fairly easy way to do it with >another shell-script wrapper. I'd still prefer a patch, though, as it's much >more efficient. Anybody offering? Well, I don't have a patch for mail, because I don't use it. I can, however, suggest a possible alternative: try installing Deliver by Chip Salzenberg. Deliver is meant to be a (considerably enhanced) replacement program for delivering local (in-system) mail msgs. While, as shipped, it has the same default lock behavior as the "standard" rmail (i.e., try 10 times to create whoever.lock and then quit), it should be trivial to change it to loop forever. (The function you want is create_lock in the file lock.c.) It can be readily put in as a "drop-in" replacement for the local mailer with smail 2.5; presumably a sendmail guru would know how to convince sendmail to pass local mail thru to deliver. Deliver should be available on your nearest friendly archive site. -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp "Cancelling a posted message means posting a cancel message."-Maarten Litmaath