Xref: utzoo comp.mail.uucp:2341 comp.mail.misc:1398 Path: utzoo!attcan!uunet!husc6!cmcl2!rutgers!gatech!bloom-beacon!spdcc!ima!minya!jc From: jc@minya.UUCP (John Chambers) Newsgroups: comp.mail.uucp,comp.mail.misc Subject: Another example why not to re-route Message-ID: <140@minya.UUCP> Date: 24 Nov 88 14:57:37 GMT Organization: (none) Lines: 73 For several days, my main newsfeed has been disabled, and due to rerouting by other machines, I have been unable to send messages along paths that should have worked. I consider this an object lesson in why rerouting is not a good idea in general. Note that I'm not objecting to routing, just rerouting. That is, if I submit some mail to foo@bar.dom.ain, I expect that mailers will figure out a route for me. But if I send mail to x.uucp!y.bitnet!bar!foo, I prefer that the mailers deliver it along exactly that route, or bounce it back to me. Oh, yes, my example. For several days now, all calls to my main newsfeed (adelie) have failed with the following in the uucp log file: | mail adelie (11/23-4:36:16,6064,0) SUCCEEDED (call to adelie ) | mail adelie (11/23-4:36:21,6064,0) HANDSHAKE FAILED (REMOTE HAS A LCK FILE FOR ME) | mail adelie (11/23-6:36:09,6111,0) SUCCEEDED (call to adelie ) | mail adelie (11/23-6:36:16,6111,0) HANDSHAKE FAILED (REMOTE HAS A LCK FILE FOR ME) | mail adelie (11/23-7:39:14,6136,0) SUCCEEDED (call to adelie ) | mail adelie (11/23-7:39:19,6136,0) HANDSHAKE FAILED (REMOTE HAS A LCK FILE FOR ME) It appears that uucico aborted without freeing the lockfile, and adelie doesn't have one of the recent (hdb) uucps that delete the lockfile if its creating process has died. So until the administrator cleans up, or uucp's garbage collector gets to it, the minya!adelie link is dead. I'd like to send mail to the administrator to tell him about it. Obviously, I can't send mail to adelie!postmaster. I do have several other neighbors, and the uucp maps show several alternative paths. I've tried sending mail along several of them, but you might guess what happens. Right. Each path includes a "smart" mailer that decides it knows a better path--going back here and across minya!adelie. Sigh. Changing the network maps isn't appropriate. The problem will clear up as soon as the lockfile goes away. In fact, I ran my "uunudge" script just before typing "postnews", and while typing this article, a call got through successfully, and the modem's RXD light is lit up solid. So the problem has just now fixed itself. But for several days, the link was down, and alternative paths all failed due to smart re-routing. Dumb mailers would have gotten the job done right. The way I like to think of this is that it's a debugging problem. Routing is fine for "normal" situations. But when things aren't normal, and the software is screwed up somehow, it isn't often correct to depend on the failing software to correct the problem. It's failing, after all. The job of debugging almost always depends on using various backdoors, spies, and out-of-band data paths to poke around in the systems innards. The major use of explicit mail paths is to diagnose and correct mail problems. A few years ago, they worked just fine for uucp. Now they don't. If we can't use them, then we won't generally be able to make email work right. The last few years of widespread smart mailers have provided us with a long list of examples, which my mailer has just extended by one. BTW, I find my "uunudge" script to be a useful debugging tool. What it does is hunt down and remove all the locks and status files blocking a given uucp link, and then starts up a "uucico -r1 -s$1" to force a call. It usually clears up any congestion caused by problems on this end. What would be really handy would be if it were installed at each of my neighbors sites, and I could say something like (uux "x!y!adelie!uunudge 'minya'"). This would have cleared up the problem without my having to contact adelie's administrator (who has better ways to spend his time than babysitting uucp, and anyhow, it's a holiday here in the USA). Unfortunately, with all the various variants of uucp around, I don't know if I could write a general, portable version of this script. Anyone interested in trying to make this a generally-available remote command? -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]