🚀 go-pugleaf

> I fire off a "uucico -r1" from cron every half-hour to clean out the
> spool area.  There are only two ports and we talk to 3 machines.
> Neither of the ports are hung.  Things are back to normal.  The
> spooling area is reasonably clean.  The logfile shows many "LOCKED
> (system name)" messages all within several minutes of each other for
> each of the systems we talk to.  There was some traffic going on at
> that point.  Any ideas?
>
There's one way this can easily happen.  If machine X has received
two or more mail messages to be forwarded to machine Y, uucico will
start up a uuxqt daemon to process them, and each one will run rmail
to forward the mail.  Each rmail will start up a new uucico to try 
to push its mail message through.  It is highly likely that they
will all run at the same time, and all but the first will generate
the LOCKED (Y) message.  

This happens here all the time.  I just ignore it.

-- 

	John M Chambers 
Phone: 617/364-2000x7304
Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos],rclex}!cdx39!{jc,news,root,usenet,uucp}
Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193
Telex: 922-443 CODEX A MNSF
Clever-Saying: For job offers please call at home (617/484-6393) evenings and weekends.

I've noticed a similiar problem with multiple uucico's going on after
rebooting and resetting the date after a power-down.  It seems that cron
likes to catch up on all the past activities it missed after the date is
reset.  If you didn't power down or reset the date before your incident
happened then I guess it was something else in your case.  But regarding
the cron/date problem, Pyramid has told me that it's a 'feature' not a
bug, and the cure is to kill cron before resetting the date... I think
the real solution though is just to have a battery backed-up clock!

In article <470@cdx39.UUCP>, jc@cdx39.UUCP (John Chambers) writes:
> > I fire off a "uucico -r1" from cron every half-hour to clean out the
> > spool area...		     ...The logfile shows many "LOCKED
> > (system name)" messages all within several minutes of each other for
> > each of the systems we talk to.  There was some traffic going on at
> > that point.  Any ideas?
> >
> There's one way this can easily happen.  If machine X has received
> two or more mail messages to be forwarded to machine Y, uucico will
> start up a uuxqt daemon to process them, and each one will run rmail
> to forward the mail.  Each rmail will start up a new uucico to try 
> to push its mail message through.  It is highly likely that they
> will all run at the same time, and all but the first will generate
> the LOCKED (Y) message.  

There is a fix for this.  If you are calling uucico -r1 every half hour
anyway, there is no reason for rmail to fire up a uucico for each
mail message.  Change rmail to call "uux -r" rather than just "uux".
If you run sendmail, you can change this in the mailer definition
for uucp -- search for "Muucp" in sendmail.cf.  If you are on a binary
site without sendmail, you may be able to fake this by moving uux to
"uux.real" and making a small shell script for uux that just calls
the real one, adding the -r flag.  Some versions of Unix can't "exec"
a shell script though -- in that case, you go one more level and
write a little C program that does {system("uux.script");}, put the
shell script in uux.script, and put the C program in uux.  And complain
to whoever supplies your Unix system that they should fix both the
kernel (so it can exec shell scripts) and rmail (so it includes uux -r).
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa
    "I can't think of a better way for the War Dept to spend money than to
  subsidize the education of teenage system hackers by creating the Arpanet."