henry@utzoo.UUCP (Henry Spencer) (10/22/85)
For unknown reasons, early this morning ihnp4 refused to accept about
a dozen files from us. Our rather old uucp doesn't do anything intelligent
in this case, so whatever they were, they're gone. A few bits of mail
going through us for ihnp4 probably got lost as a result.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryhoney@down.FUN (Peter Honeyman) (10/24/85)
henry complains about ihnp4 refusing mail "for unknown reasons."
prepare to have the unknown made known.
one of the advantages of honey danber is the spool directory hashing
scheme: a separate directory for each host. a disadvantage is that
these directories hang around forever, clogging the spool directory.
thus, busy sites like ihnp4 periodically rmdir spool/* to clean up
(and thus to speed up).
now, if utzoo is talking to ihnp4, and the rmdir daemon happens to
catch the utzoo directory when it's empty, subsequent requests to
transfer from utzoo to ihnp4 will fail miserably. this is a bug.
this happened to me a few months ago -- 10 mail messages were dropped.
i was pissed off! off to the source code; what to do, what to do!?
i decided that if a request to send a /-free file is denied, then the
remote is horribly broken. accordingly, i changed cntrl.c to hang up
in those circumstances -- maybe things will be ok later. this worked
great -- i even got rick to buy in -- until disaster struck. disaster
in the form of honey danber.
if i transfer a file, but lose the connection before receiving the
acknowledgement, i try again the next time i establish a link. but
now, the remote refuses the request -- honey danber won't overwrite an
existing work file. gack! -- this meets the criterion above so i hang
up, only to try again later. and later. and forever, never sending
another damn thing.
i queried dan -- "what were we thinking of in refusing to overwrite" --
he indicated that maybe it was an optimization (spare me!). the
temptation to remove the refusal from the code is ineffectual, since
this bug will live forever somewhere in "the field."
there you have it. mea culpa. (you-a too dave, and-a you brian!)
back to ihnp4. i keep asking them to stop exposing my bugs, but they
just don't listen. for the last time, please stop it! here's a script
that removes empty directories in a clean way. (test it first!)
peter
#!/bin/sh
lockdir=/usr/spool/locks
cd /usr/spool/uucp
locklink=$lockdir/rmdir-daemon
echo $$ | awk '{printf("%10d\n", $1)}' > $locklink
for i in [a-z]*; do
lockfile=$lockdir/`echo LCK..$i|cut -c1-14`
ln $locklink $lockfile && rmdir $i
rm -f $lockfile
done
rm -f $locklink
exit 0mikel@codas.UUCP (Mikel Manitius) (10/26/85)
> For unknown reasons, early this morning ihnp4 refused to accept about > a dozen files from us. Our rather old uucp doesn't do anything intelligent > in this case, so whatever they were, they're gone. A few bits of mail > going through us for ihnp4 probably got lost as a result. > -- > Henry Spencer @ U of Toronto Zoology Has anyone else had this problem? I have stuff queued to ihnp4 for a couple of days once, and I also once has something denied by them, at other times it's really slowwwww. What is going on? -- Mikel Manitius @ AT&T-IS Altamonte Springs, FL ...{ihnp4|akguc|attmail|indra!koura}!codas!mikel
nyssa@abnji.UUCP (nyssa of traken) (10/31/85)
ihnp4 has refused files from us recently as well, they too were lost.
The message we received was that it couldn't create a file, and it
looked like a space problem on their machine.
When I send mail, I archive a copy of what I send, I just resent it,
but if you have no archive, it can be a problem.
--
James C. Armstrong, Jnr. {ihnp4,cbosgd,akgua}!abnji!nyssadhp@ihnp3.UUCP (Douglas H. Price) (11/02/85)
Ihnp4 has been having some problems. Recent configuration changes in np4's file system broke netnews for a while between 10/24 (a Thursday) and 10/28 (a Sunday). Hopefully, these problems have been corrected, but netnews flowing towards ihnp4 during the days mentioned where not properly forwarded, and should be considered lost. -- Douglas H. Price Analysts International Corp. @ AT&T Bell Laboratories ..!ihnp4!ihnp3!dhp
larry@kitty.UUCP (Larry Lippman) (11/12/85)
> > For unknown reasons, early this morning ihnp4 refused to accept about > > a dozen files from us. Our rather old uucp doesn't do anything intelligent > > in this case, so whatever they were, they're gone. A few bits of mail > > going through us for ihnp4 probably got lost as a result. > Has anyone else had this problem? I have stuff queued to ihnp4 for a > couple of days once, and I also once has something denied by them, > at other times it's really slowwwww. What is going on? We try to send to ihnp4 at 2400 baud as a first call attempt, and I have noticed that many of our 2400 baud call attempts fail becase their 2400 baud lines sometimes do not answer. So, our uucico tries again at 1200, which generally works - but at twice the cost... Hello, ihnp4? === Larry Lippman @ Recognition Research Corp., Clarence, New York === === UUCP {decvax,dual,rocksanne,rocksvax,watmath}!sunybcs!kitty!larry === === VOICE 716/741-9185 {rice,shell}!baylor!/ === === FAX 716/741-9635 {AT&T 3510D} ihnp4!/ === === === === "Have you hugged your cat today?" ===
dhp@ihnp3.UUCP (Douglas H. Price) (11/15/85)
The 2400 baud dialup for ihnp4 is a temporary lashup until (an already aquired) pool of AT&T 2400 baud modems come on line. The Paradyne ARK 2400 modem we have on loan (with the new ROM) occasionally gets itself into a hung state which requires pulling the plug to fix. My apologies for the current inconvenience. -- Douglas H. Price Analysts International Corp. @ AT&T Bell Laboratories ..!ihnp4!ihnp3!dhp
phil@amdcad.UUCP (Phil Ngai) (11/16/85)
We had/have trouble with a completely different ARK product, their 56K
DDS mini-mux. We never could get it to do something they advertised it
would do, and in the mode we are currently using it, we have problems
every once in a while although we don't know exactly what part of our
network is at fault. I have also found their applications engineers to
be very defensive and unhelpful.
Their little boxes, like their modem eliminators, seem to work well.
But I am not surprised to hear their 2400 baud modem is flaky.
--
Raise snails for fun and profit! Race them for amusement! Then eat the losers!
Phil Ngai +1 408 749-5720
UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
ARPA: amdcad!phil@decwrl.dec.com