[net.bugs.uucp] 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

honey@down.UUCP (06/05/84)

the answer (i.e., the gospel according to honey danber (when the hell
is it going to be released, dave?)) is for uucico to examine the C.
file and move it off to a safe place if it looks corrupted.  (the
alternative, dumping core, is less than attractive.)  our hook is in
anlwrk(); after calling getargs(), we make sure the line is type R or
type S and that enough args were present.
	peter honeyman