chip@t4test.UUCP (Chip Rosenthal) (02/09/85)
I seem to fairly frequently get UUCP messages with uucico garbage strewn
through them. I'm attaching an example of such a message below. Because
of the nature of the garbage, it looks like a uucico problem. Also, I've
seen it happen with all of our UUCP partners, which leads me to believe
that it is my uucico which is doing this. We are running Eunice here, so
I am wondering if its uucp software is causing the problem. Has anybody
out there seen this kind of thing? Any suggestions what to do? (If it
involves poking around in the guts of uucico I can't do it; we don't have
source.) Thanks in advance.
Edited copy of trashed message follows:
----- message begins ------------------------------------------------------
From uucp Fri Feb 8 03:03:47 1985
wmesg 'S'Y
send 37777777611
rec h->cntl 41
state - 10
rec h->cntl 37777777621
send 42
rec h->cntl 37777777631
send 43
.
. (similar stuff repeated for 20 more lines)
.
rec h->cntl 37777777601
send 40
rec h->cntl 37777777611
send 41
>From tektronix.UUCP!uw-beaver!ubc-vision!mprvaxa!sonnens Fri Feb 8 03:42:38 1985 remote from cbosgd
From: cbosgd!tektronix.UUCP!uw-beaver!ubc-vision!mprvaxa!sonnens
Received: by cbosgd.ATT.UUCP (4.12/3.7)
id AA04074; Fri, 8 Feb 85 03:42:38 est
.
. (mail message continues)
.
available, I'll be glad to send you copies, by electronic or conventional
mail. These arec h->cntl 37777777621
send 42
rec h->cntl 37777777631
send 43
rec h->cntl 37777777641
send 44
rec h->cntl 37777777751
send 45
rec h->cntl 37777777761
send 46
rticles were very abbreviated, but tried to give all the
essentials in a clear way. I would be interested in your comments.
received data 1263 bytes 13 secs
----- message ends --------------------------------------------------------
--
Chip Rosenthal, Intel/Santa Clara
{cbosgd,idi,intelca,icalqa,kremvax,qubix,ucscc} ! {t4test,t12tst} ! {chip,news}stein@fortune.UUCP (Mark Stein) (02/11/85)
> I seem to fairly frequently get UUCP messages with uucico garbage strewn > through them. I have seen this happen when uucico can't open the AUDIT file for writing out debug messages (those lines which magically appeared in your mail messages). What's happening is that uucico, when started up in slave mode, always attempts to open $SPOOL/AUDIT (/usr/spool/uucp/AUDIT) as stderr. This is attempted by first closing stderr, then doing an fopen on AUDIT. Too bad that fopen's return code is not checked! So, when the data file is later opened, it returns file descriptor 2, and all debug output being written to stderr gets into the data. (Some versions do an 'freopen' call instead of the flose/fopen pair.) The no-source fix is to make sure that $SPOOL/AUDIT exists and is writable by user uucp (or whatever user name your copy of uucico is setuid'd to). The proper fix is to modify cico.c to check the return code when it opens RMTDEBUG. And then to take appropriate action if it failed. Mark Stein Fortune Systems ihnp4!fortune!stein