Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!princeton!udel!burdvax!bpa!cbmvax!vu-vlsi!cgh!amanue!jr
From: jr@amanue.UUCP (Jim Rosenberg)
Newsgroups: comp.unix.questions
Subject: Re: How to prevent low-grade uucp work during daytime?
Message-ID: <231@amanue.UUCP>
Date: Thu, 13-Aug-87 13:14:14 EDT
Article-I.D.: amanue.231
Posted: Thu Aug 13 13:14:14 1987
Date-Received: Sun, 16-Aug-87 12:01:08 EDT
References: <3572@cit-vax.Caltech.Edu>
Organization: Amanuensis Inc., Grindstone, PA
Lines: 48
Summary: You could put a "tap" into /usr/lib/uucp/uuxqt (or SPOOLNEWS!)

In article <3572@cit-vax.Caltech.Edu>, mangler@cit-vax.Caltech.Edu (System Mangler) writes:
> [4.3 BSD]
> 
> Our uucp gateway is overloaded during the daytime, so I want to
> limit the times of day that low-grade work such as news can be
> transferred, while still allowing mail at any time.
> 
> Don Speck   speck@vlsi.caltech.edu  {rutgers,amdahl}!cit-vax!speck

This solution is admittedly *extremely* ucky, bit it will work.  I'm assuming
that most of your unwanted load is coming from mail and news, which are really
uux'ing to your system.  It *won't* do anything to defer a true uucp, i.e. a
transfer carried out by uucico.

I don't know about Berkeley, but under System V there seems to be no harm done
at all by deferring /usr/lib/uucp/uuxqt and then running it again later.  The
files sit around in the spool directory, but when uuxqt is really run then the
work is performed as normal.  You could rename /usr/lib/uucp/uuxqt to
/usr/lib/uucp/uuxqt.real, then write a program which you call
/usr/lib/uucp/uuxqt.  Your program would get the time, and consult a file to
see if it was OK to run real uuxqt.  If it was OK then it would simply exec
/usr/lib/uucp/uuxqt.real.  If not it would simply exit, perhaps making an
entry in a log file.  Note that if you did this, a superuser could fire off
the spooled work any time, should your load happen to be light, e.g. during
lunch, by simply executing /usr/lib/uucp/uuxqt.real by hand from a shell.

I'm running such a "tap" in my own uuxqt.  My news link is running a different
version of batcher, and I put in the tap in case he changes over to the same
one I'm running now, so that I can preserve my spool directory files in case
something's broke.  My tap links all the spool directory files for a uucp xfer
to a /usr/tmp/uucp directory, which is cleaned out by cron.  It ain't pretty,
but is pretty useful.  It lets me go back the last 48 hours and resurrect any
transaction which seems to have gotten fouled up.

My serious hands-on experience is V7 and System V, so there may be some slight
differences to get this to work under BSD, but I'm assuming the same general
idea would work.

Of course, if news is the only problem, you could just rebuild news and set
the SPOOLNEWS option.  This does exactly what you want:  the incoming news
just sits around in a spool directory until rnews -U is invoked, presumably
from cron.  All the serious cpu/disk load from rnews only happens when you do
rnews -U.
-- 
 Jim Rosenberg
     CIS: 71515,124                         decvax!idis! \
     WELL: jer                                   allegra! ---- pitt!amanue!jr
     BIX: jrosenberg                 seismo!cmcl2!cadre! /