Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1+some 2/3/84; site dual.UUCP Path: utzoo!linus!decvax!decwrl!dual!fair From: fair@dual.UUCP (Erik E. Fair) Newsgroups: net.bugs.uucp,net.mail Subject: dual -> ihnp4 UUCP lossage on 10/17 Message-ID: <845@dual.UUCP> Date: Thu, 18-Oct-84 16:54:56 EDT Article-I.D.: dual.845 Posted: Thu Oct 18 16:54:56 1984 Date-Received: Fri, 19-Oct-84 06:48:16 EDT Distribution: net Organization: Dual Systems, Berkeley, CA Lines: 48 Last night when ihnp4 called us, we had 17 messages queued for them. Something was wrong with the UUCP spool directory on ihnp4 (this surmised from the LOGFILE and the nasty notes I got back from UUCP) and ihnp4 rejected all attempts to send it stuff with ``access to remote path/file denied.'' As a result, all 17 messages were dumped down the proverbial bit bucket. While the problem appears to have been fixed relatively quickly (they called us again this morning, and all went well; a tribute to Gary Murakami and the other people who run ihnp4), 17 people somewhere are going to wonder who dropped their mail on the floor. This is one of the reasons that UUCP is considered ``unreliable.'' When something goes wrong in the transport, there is no way to get back to the original requestor if the transaction was mail, because the mail program is not an active part of the actual transport. Now for Peter Honeyman: since ihnp4 is running honey danber UUCP, the question comes up about the UUCP spool directory and what UUCP should do when it isn't accessable for some reason. Currently, when you try and initiate a transfer, UUCP will check the path to see if it can write on it (both through access(2) and the USERFILE). If the path is inaccessable, UUCP will send an error code back to the requesting remote, which will in turn delete the request and mail a note back to who it thinks is the requestor that the transfer failed. For actual ``uucp'' requests, this is reasonable. For mail (uux), it sucks. My inclination is to say that if the requesting side gets back an error on path/file access, and the destination was the remote system's UUCP spool directory, UUCP should: 1) notify ``uucp'' by mail that a request failed. (i.e. put a human being in the loop) 2) Keep the request around, on the assumption that the remote has a temporary problem (consequently trying again later) Given this view of things, clearly my System V UUCP was at fault (for deleting the requests). I'm curious though, what honey danber would do if the positions had been reversed? Erik E. Fair ucbvax!fair fair@ucb-arpa.ARPA dual!fair@BERKELEY.ARPA {ihnp4,ucbvax,hplabs,decwrl,cbosgd,sun,nsc,apple,pyramid}!dual!fair Dual Systems Corporation, Berkeley, California P.S. This can also be considered notice that other systems might have had problems with UUCP to ihnp4 last night.