[net.unix-wizards] UUCP ignoring work requests

dyer@wivax.UUCP (Stephen Dyer) (06/01/84)

As long as we're airing our UUCP bugs in public...

Every now and then, work requests (from mail) to one particular machine
pile up in our /usr/spool/uucp without being transferred.  That is,
polling the other site causes a successful connection, but no data
is transferred (and vice versa.)  This seems to spontaneously clear
itself after about a week--I have no idea yet what is going on at
the other end.

Before I start spelunking in the code, I wondered if any others out there
have seen this or similar behavior before, and whether they have any
theories.
-- 
/Steve Dyer
decvax!bbncca!sdyer
sdyer@bbncca.ARPA

larry@decvax.UUCP (Larry Cohen) (06/04/84)

I have seen this phenomena also  (not sending out spooled files
for a period of time).  In the cases I have seen the problem
is related to corrupted C. files.  Every so often (couple of times a year)
I have found a C.file that appears to contain the output of 
a news or mail data file.  Most versions of uucico will read a line in 
this C. file and determine that there are too many arguments and subsequently
exit via an ASSERT call.  This explains why no files are transferred - uucico
never gets past the bad C.file.
The reason things clear up after a week (at least on the systems I have worked
on) is that we have a crontab shell script which will remove files which
have been sitting around too long (usually a week).
I dont know why the bad C.files appear but I have been able to work
around the problem by having uucico move the corrupted C.files to a safe place 
- something like /usr/spool/uucp/BADCFILES.
If anyone knows the the answer to the corrupted C.file problem I would sure
like to know.

						-Larry Cohen
						 decvax!larry

mm1751@ALMSA-1.ARPA (07/24/84)

From:      Mary Mallott <mm1751@ALMSA-1.ARPA>

We have been having cases where uucp spools the files to sent (D.) but
there is no C. file created.  Actually, you can see that the C. directory
was updated at the same time as the D. directory, but the file is gone.

We're running 4.2, the uucp connection is a direct line with the other system
calling us.

Mary Mallott
US Army ALMSA
St. Louis, Mo
mmallott@almsa-1

jim@ism780b.UUCP (08/01/84)

#R:wivax:-1957400:ism780b:28500007:000:90
ism780b!jim    Jul 20 12:35:00 1984

> As long as we're airing our UUCP bugs in public...

This stuff belongs in net.bugs.uucp