INN Feed Refused Anteil

[smash]

Moin Freunde,

ich habe im Moment einen aktiven incoming feed und sehe fuer z.b.
gestern 27k offered und 13k refused. Also nur knapp die haelfte
angenommen. Ich habe Fragen...

Die wichtigste: wie bekomme ich INN dazu mir wirklich verbose in die
Logs zu schreiben was es tut. In diesem Fall halt: welche Message-ID
wird angeboten, welche refused.

Da ich ja nur einen feed habe, ist es ziemlich ausgeschlossen dass die
Nachrichten refused werden weil der server sie schon kennt (oder?).
Liegt es vielleicht daran dass der feed zwei connections offen hat und
ueber beide gleichzeitig dieselbe Nachricht anbietet?

So sieht das im Log aus:
Nov 12 10:55:00 news innd[14485]: ME status seconds 180 accepted 25
refused 25 rejected 0 duplicate 0 accepted size 58236 duplicate size 0
rejected size 0


cheers,
smash

[Daniel Weber]

Post by smash
Da ich ja nur einen feed habe, ist es ziemlich ausgeschlossen dass die
Nachrichten refused werden weil der server sie schon kennt (oder?).
Liegt es vielleicht daran dass der feed zwei connections offen hat und
ueber beide gleichzeitig dieselbe Nachricht anbietet?

Dein Peer hat nicht nur (mindestens) zwei Connections offen sondern hat
auch zwei (geographisch verteilte) Feeder. Deswegen wird Dir jede
Nachricht i.d.R. zweimal angeboten. Das passt also schon so.

Ciao
Daniel

[Thomas Hochstein]

Post by smash
Die wichtigste: wie bekomme ich INN dazu mir wirklich verbose in die
Logs zu schreiben was es tut. In diesem Fall halt: welche Message-ID
wird angeboten, welche refused.

"refused" bedeutet, dass das Posting abgelehnt wird, weil die Message-ID
bereits in der History steht, also das Posting normalerweise bereits
angenommen wurde. Ich wüsste nicht, dass das irgendwo vertieft gelogged
wird; wozu auch? :)

Post by smash
Da ich ja nur einen feed habe, ist es ziemlich ausgeschlossen dass die
Nachrichten refused werden weil der server sie schon kennt (oder?).

"refused" bedeutet, er kennt sie schon.

"rejected" bedeutet, dass er das Posting aus anderen Gründen nicht
annimmt. Das wird in /var/log/news/news gelogged.

-thh

[smash]

Post by Thomas Hochstein
"refused" bedeutet, dass das Posting abgelehnt wird, weil die Message-ID
bereits in der History steht, also das Posting normalerweise bereits
angenommen wurde. Ich wüsste nicht, dass das irgendwo vertieft gelogged
wird; wozu auch? :)

vielen dank, der unterschied refused/rejected war mir nicht klar. btw.
was meint duplicate?

mit etwas umfangreicherem logging logging haette ich mir das vermutlich
auch ableiten koennen. und da finde ich inn etwas schizo. auf der einen
seite bekomme ich vom nnrpd fast zeilenweise geloggt wie er die
readers.conf durchwuehlt auf der suche nach dem passenden hit - aber
nachrichten die der server rejected tauchen lediglich in der statistik
auf. fuer sowas finde ich es halt immer gut wenn ich mittels -v -vv -vvv
etc detaillierter loggen kann wenn sonderbare dinge passieren.

aber das soll jetzt nicht darueber hinwegtaeuschen dass ich die antwort
auf meine frage mit ausfuehrlicherem doku lesen vermutlich selber haette
finden koennen ;)

smash

[Thomas Hochstein]

Post by smash
vielen dank, der unterschied refused/rejected war mir nicht klar. btw.
was meint duplicate?

Das sind Duplikate, die quasi gleichzeitig angeboten werden, so dass sie
nicht refused werden (weil sie schon in der History stehen), sondern
zunächst angenommen, dann aber verworfen.

Der sendende Server teilt zunächst per "IHAVE msgid" mit, dass er einen
Artikel senden möchte. Wenn der empfangende Server ihn schon - in der
History - hat, lehnt er ihn ab; das ist "refused". Sonst lässt er ihn
sich schicken. Kommt ein Artikel von mehreren Peers quasi gleichzeitig
rein, lässt er ihn sich von mehreren schicken. Den ersten nimmt er an,
die anderen lehnt er - jetzt einen Schritt später im Protokoll und
"teurer", weil der komplette Artikel bereits übermittelt wurde - ab. Das
ist "duplicate".
< 435 Article not wanted

Ist die Message-ID noch nicht in der History, wenn der Absender fragt,
aber sehr wohl, bis er den Artikel übermittelt hat, sieht das bspw. so
< 335 Send article to be transferred

Post by smash
[... hier kommt der Artikel ...]

< 437 Transfer rejected; do not retry

Die Beispiele kann man sich aus RFC 3977, 6.3.2. zusammenbasteln.

Realiter kann das dann in /var/log/news/news so aussehen:
| ***@weidegrund $ grep '111120210050070073%nospam' /var/log/news/news
| Nov 11 06:50:13.884 + news.karotte.org <111120210050070073%***@nospam.invalid> (@[...]@) 1286 inpaths! [...]
| Nov 11 06:50:13.888 - szaf-out.news.weretis.net <111120210050070073%***@nospam.invalid> 439 Duplicate
| Nov 11 06:50:13.888 - news.datentrampelpfad.de <111120210050070073%***@nospam.invalid> 439 Duplicate
| Nov 11 06:50:13.889 - peer-szaf.out.news.welterde.net <111120210050070073%***@nospam.invalid> 439 Duplicate
| Nov 11 06:50:13.894 - szaf-out.feeder.erje.net <111120210050070073%***@nospam.invalid> 439 Duplicate
[...]

Post by smash
aber nachrichten die der server rejected tauchen lediglich in der
statistik auf.

Rejects werden geloggt. Duplicates auch. Refusals nicht.

Zu loggen, dass eine Nachricht nicht angenommen wird, weil sie schon
vorliegt, erscheint mir weitgehend sinnbefreit. Jede Nachricht wird nur
einmal angenommen, also müsste man bei den anderen 20, 40 oder 400 Peers
jeweils loggen, dass sie nicht angenommen würde - mit welchem
Erkenntnisgewinn für eine zusätzliche Logzeile pro Peer und Artikel?

Post by smash
aber das soll jetzt nicht darueber hinwegtaeuschen dass ich die antwort
auf meine frage mit ausfuehrlicherem doku lesen vermutlich selber haette
finden koennen ;)

Die Doku zum INN ist nicht schlecht; das Problem ist nur, zu finden, wo
was steht. Die Lognachrichten des innd habe ich auf die Schnelle nicht
dokumentiert gefunden, wohl aber die Gegenrichtung, d.h. das Logging von
innfeed. In "man innfeed" steht dann
| SYSLOG ENTRIES
[...]
| refused
| The number of articles offered to the host that it indicated it did
| not want because it had already seen the message-ID. The remote host
| indicates this by sending a 435 response to an IHAVE command or a 438
| response to a CHECK command.
|
| rejected
| The number of articles transferred to the host that it did not accept
| because it determined either that it already had the article or it
| did not want it because of the article's Newsgroups: or Distribution:
| header fields, etc. The remote host indicates that it is rejecting
| the article by sending a 437 or 439 response after innfeed sent the
| entire article.

-thh

[smash]

Post by Thomas Hochstein

Post by smash
vielen dank, der unterschied refused/rejected war mir nicht klar. btw.
was meint duplicate?

Das sind Duplikate, die quasi gleichzeitig angeboten werden, so dass sie
nicht refused werden (weil sie schon in der History stehen), sondern
zunächst angenommen, dann aber verworfen.

ergibt sinn, danke! :)

Post by Thomas Hochstein
Der sendende Server teilt zunächst per "IHAVE msgid" mit, dass er einen
Artikel senden möchte. Wenn der empfangende Server ihn schon - in der
History - hat, lehnt er ihn ab; das ist "refused". Sonst lässt er ihn
sich schicken. Kommt ein Artikel von mehreren Peers quasi gleichzeitig
rein, lässt er ihn sich von mehreren schicken. Den ersten nimmt er an,
die anderen lehnt er - jetzt einen Schritt später im Protokoll und
"teurer", weil der komplette Artikel bereits übermittelt wurde - ab. Das
ist "duplicate".

musste gerade mal nachgucken weil das szenario mir so bekannt vorkam -
hat mich an 'wipcheck' erinnert:

wipcheck
If INN is offered an article by a peer on one channel, it will
return deferral responses (code 436) to all other offers of that
article for this many seconds. (After this long, if the peer
that
offered the article still hasn't sent it, it will be accepted
from
other channels.) The default value is 5 and probably doesn't
need
to be changed.

Post by Thomas Hochstein
Die Doku zum INN ist nicht schlecht; das Problem ist nur, zu finden, wo
was steht. Die Lognachrichten des innd habe ich auf die Schnelle nicht

ack, ist im moment noch angenehm viel neuer input zum thema. jedes
configfile hat seine eigene umfangreiche manpage, finde ich sehr angenehm.

Post by Thomas Hochstein
dokumentiert gefunden, wohl aber die Gegenrichtung, d.h. das Logging von
innfeed. In "man innfeed" steht dann

wird heute meine bettlektuere!

cheers,
smash