pete@esosun.esosun.UUCP (Pete Ware) (11/12/86)
We are running Sun 4.2bsd release 3.1 and uucp based on the rti uucp
from the 4.2bsd tape as modified by Rick Adams. When I logged on this
morning there were many (as in more than 20) uucico's going (not since
I was a student have I seen the load average above 50, until now).
Why? How?
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?
Thanks,
--
{seismo,sdcsvax!net1}!esosun!pete (Pete Ware) (619) 458-2520jc@cdx39.UUCP (John Chambers) (11/13/86)
> 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.
perry@vu-vlsi.UUCP (Rick Perry) (11/16/86)
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!
gnu@hoptoad.uucp (John Gilmore) (11/20/86)
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."