Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/12/84; site desint.UUCP
Path: utzoo!watmath!clyde!cbosgd!ulysses!bellcore!decvax!decwrl!pyramid!hplabs!sdcrdcf!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: net.news.adm,net.news.b
Subject: Re: curious 2.10.3 efficiency situation
Message-ID: <175@desint.UUCP>
Date: Tue, 11-Mar-86 19:48:29 EST
Article-I.D.: desint.175
Posted: Tue Mar 11 19:48:29 1986
Date-Received: Fri, 14-Mar-86 07:47:47 EST
References: <10428@amdcad.UUCP> <5128@glacier.ARPA> <63@gilbbs.UUCP>
Reply-To: geoff@desint.UUCP (Geoff Kuenning)
Organization: SAH Consulting, Manhattan Beach, CA
Lines: 53
Xref: watmath net.news.adm:557 net.news.b:1316

Before I get to my real point, I can't resist defending Phil Ngai:

In article <5128@glacier.ARPA>, reid@glacier.ARPA (Brian Reid) writes:
> 
> Grumble. Don't tell me that this didn't happen. It did.
> 
> It is absolutely true that the time to process one news article increased
> substantially while the torrent was arriving.

Brian, I don't think Phil ever said that your load spike didn't happen.
He simply said that the facts you posted in your original article
didn't support blaming queing for all of your problems.  This second article
(5128@glacier) gave more data, explaining that the arrival rate in your
queues had increased due to the increased service time;  this makes
your explanation much more plausible.  However, I still think that if
you have more than one UUXQT running you have a problem because (a)
you're quite possible thrashing, and (b) with the possible exception of
Honey Danber (Peter? any comment?) no uucp system should allow more
than one UUXQT at a time.  Which brings me to my main point:

In article <63@gilbbs.UUCP> mc68020@gilbbs.UUCP (Tom Keller) writes:

>   I understand there is some way to ensure that only one istantiation of
> UUXQT is executed at any one time.  Can someone elaborate on this for me?
> I am very new to all this (I've never had to consider such things in my
> 3 years of using XENIX.  I have no gurus to point out the True Path to me).

Actually, Tom, the rumor reached you in a bit of a confused state.  All
systems should limit uuxqt's to one-at-a-time.  Unfortunately, there's
a bug in older systems:  the original uucp authors simply never foresaw
the day of hours-long uuxqt's, and they wrote uuxqt to ignore the lock
file if it was more than 50 minutes old.  Later systems either fixed the bug,
or switched to a more reliable locking mechanism that doesn't depend on
timeouts to break hung locks.

Fortunately, the workaround is extremely easy:  you simply have to ensure that
the uuxqt lock file is always less than an hour old.  This can be done
with the following crontab entry:

    15,45 * * * * * if [ -r /usr/spool/uucp/LCK.XQT ] ; then
	touch /usr/spool/uucp/LCK.XQT ; fi

(note that this has to fit all on one line, unlike the way I typed it).

One minor problem:  make sure your /etc/rc file has the line

    rm -f /usr/spool/uucp/LCK.XQT

or, once you have had a uuxqt crash, you will never run uuxqt's again!
-- 

	Geoff Kuenning
	{hplabs,ihnp4}!trwrb!desint!geoff