Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site fortune.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!fortune!stein From: stein@fortune.UUCP (Mark Stein) Newsgroups: net.eunice,net.bugs.uucp Subject: Re: uucico trashes messages Message-ID: <4990@fortune.UUCP> Date: Sun, 10-Feb-85 23:09:04 EST Article-I.D.: fortune.4990 Posted: Sun Feb 10 23:09:04 1985 Date-Received: Mon, 11-Feb-85 06:34:11 EST References: <1332@t4test.UUCP> Distribution: net Organization: Fortune Systems, Redwood City, CA Lines: 25 Xref: watmath net.eunice:197 net.bugs.uucp:448 > 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