dyer@spdcc.COM (Steve Dyer) (09/25/90)
I seem to get periods of hours at a time when my NNTP feeds send me
articles which generate syslog messages of the form:
Sep 25 01:29:07 ursa-major nntpd[20793]: /usr/local/bin/rnews: inews: : Inbound news is garbled
Sep 25 01:29:08 ursa-major nntpd[20793]: spawn: /usr/local/bin/rnews exit status 1
Does anyone know what might be going on, and whether it's something I should
be worrying about? Is it a problem with my software or at the senders end?
Is there a way to patch this? I'm running B news 2.11.19.
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edukarl_kleinpaste@cis.ohio-state.edu (09/25/90)
dyer@spdcc.com writes:
I seem to get periods of hours at a time when my NNTP feeds send me
articles which generate syslog messages of the form:
/usr/local/bin/rnews: inews: : Inbound news is garbled
/usr/local/bin/rnews exit status 1
Does anyone know what might be going on, and whether it's something I should
be worrying about? Is it a problem with my software or at the senders end?
Is there a way to patch this? I'm running B news 2.11.19.
The problem is that the feed site is trying to ship you an article
with a badly formatted message-id; it is probably in the References:
header. Ask your feed site to mail you a copy of the article in
question (see your errlog for the Message-ID it's trying to send you).
When this started happening to me some months ago, I determined only
that [a] it happens to articles which are generated at C News sites,
and [b] only comes to me this way from neighbors which are running C
News. NNTP B News neighbors of mine do not cause this behavior. I
suggested to Henry a couple of months ago that perhaps a buffer was
being overrun, but he adamantly denied such a thing, because C News
doesn't do any such buffer-related things to headers. (Or something
like that; it was at least 2 months ago, maybe more, and I don't know
what the guts of C News are like, so my memory doesn't key off the
relevant details.)
The problem either goes away on its own (this appears to be related to
some other neighbor site running B News giving me the article, so that
the next IHAVE from the C News neighbor is rejected), or I write mail
to the relevant admins.
The sites which cause this on my site are snorkelwacker.mit.edu (was
beating me up yesterday with
<1990Sep24.084428.12410@rodan.acs.syr.edu.toronto.edu>
-- some 84 times) and usenet.ins.cwru.edu. Occasionally others.
--karl
PS- Also running B 2.11.19.tale@turing.cs.rpi.edu (David C Lawrence) (09/25/90)
In article <KARL.90Sep25105129@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: The problem is that the feed site is trying to ship you an article with a badly formatted message-id; it is probably in the References: header. The sites which cause this on my site are snorkelwacker.mit.edu (was beating me up yesterday with <1990Sep24.084428.12410@rodan.acs.syr.edu.toronto.edu> -- some 84 times) and usenet.ins.cwru.edu. Occasionally others. I do not know about cwru but the admin at Syracuse has told us that he is trying to solve the problem of a couple of bass-ackwards machines under his domain shipping articles without a Date: header. Nothing to do with Message-ID:, though it isn't quite right. Ditto for the site at Umich which was sending out articles that a newline in the comment field of Sender: but no preceeding whitespace on the continuation line; they apparently fixed that problem. (Maybe the latest problems are some bad message-ids though.) This is how it affects me bombarding other sites. The ones which have failures below are B News. I am C News, as are the ones which don't have failures. Sorry guys. Article Transmission Offered Took Toss Fail Host Contacted Total Minutely Total Minutely Pct Total Pct Total Pct theory.tn.cornell.ed 5550 5.10 5488 4.93 99% 62 1% 0 0% leah.albany.edu 9000 39.07 6016 12.86 67% 2984 33% 1869 21% sci.ccny.cuny.edu 5700 7.43 5691 7.41 100% 9 0% 1 0% gdstech.grumman.com 5136 N/A 5136 N/A 100% 0 0% 3 0% zaphod.mps.ohio-stat 900 9.96 311 0.26 35% 587 65% 0 0% uwm.edu 12300 52.28 2384 2.72 19% 9914 81% 2174 18% muvms3.mu.wvnet.edu 50 N/A 50 N/A 100% 0 0% 0 0% news.clarkson.edu 6000 26.95 5525 21.54 92% 464 8% 5 0% julius.cs.uiuc.edu 5150 4.25 3534 2.84 69% 1613 31% 0 0% uu.psi.com 5600 6.77 5467 5.92 98% 131 2% 0 0% bu.edu 20750 38.05 8659 8.10 42% 12091 58% 7614 37% dali.cs.montana.edu 11350 35.13 4026 3.05 35% 7321 65% 2799 25% masscomp.westford.cc 6700 70.63 1587 2.93 24% 5111 76% 701 10% mts.rpi.edu 2876 N/A 2876 N/A 100% 0 0% 0 0% crdgw1.ge.com 40350 68.23 5422 6.83 13% 34924 87% 3946 10% -------------------- --------------- ------------------ ---------- ---------- TOTALS 137412 30.32 62172 6.62 45% 75211 55% 19112 14% -- (setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet")) I'm worried about the baggage retrieval system they've got at Heathrow.
anselmo-ed@cs.yale.edu (Ed Anselmo) (09/25/90)
>>>>> On 25 Sep 90 14:51:29 GMT, karl_kleinpaste@cis.ohio-state.edu said:
Karl> The problem either goes away on its own (this appears to be related to
Karl> some other neighbor site running B News giving me the article, so that
Karl> the next IHAVE from the C News neighbor is rejected), or I write mail
Karl> to the relevant admins.
When I have nothing else to do, I grab the article from another site,
fix it up, and re-inject it. Since "nothing else to do" is a rare
condition, I didn't get to do this with yesterday's batch of articles.
This particular article didn't have a "Date:" header.
Karl> The sites which cause this on my site are snorkelwacker.mit.edu (was
Karl> beating me up yesterday with
Karl> <1990Sep24.084428.12410@rodan.acs.syr.edu.toronto.edu>
Karl> -- some 84 times) and usenet.ins.cwru.edu. Occasionally others.
Yale got offered this article 589 times yesterday (490 or so times
from mintaka.lcs.mit.edu, about 80 times from ox.com, the rest of the
time from umich.edu) from all of its C News neighbors.
Karl> PS- Also running B 2.11.19.
Likewise.
--
Ed Anselmo anselmo-ed@cs.yale.edu {harvard,cmcl2}!yale!anselmo-edfair@ucbarpa.Berkeley.EDU (Erik E. Fair) (09/26/90)
You all should be aware that there is a fundamental assumption in the NNTP 1.5 nntpxmit program (which was safe to make at the time that I wrote it): failures are transient. If there is a non-transient failure in the remote, the sending system will pound the remote with all the articles that cause the failure until the articles are either: 1. successfully accepted by the remote 2. expired on the sending system The previous behavior was that failures were logged, but the article was not reoffered, because there was no requeue code in nntpxmit. This meant that unless you have redundant feeds, you stand to lose some news to transient failures. I chose to try and reduce this possibility, and all testing done prior to release indicated that all failures seen by nntpxmit from the remote were indeed transient. So why did I bring this up? Well, the failure counts could be caused by one article being repeatedly failed by the remote, until it is accepted later on... Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu