Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
INN Feed Refused Anteil
1 view
Skip to first unread message
smash
Nov 12, 2021, 6:05:07 AM11/12/21
to
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
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
Nov 12, 2021, 8:22:46 AM11/12/21
to
Am 12.11.2021 um 12:05 schrieb 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
> 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?
auch zwei (geographisch verteilte) Feeder. Deswegen wird Dir jede
Nachricht i.d.R. zweimal angeboten. Das passt also schon so.
Ciao
Daniel
Thomas Hochstein
Nov 12, 2021, 11:15:02 AM11/12/21
to
smash schrieb:
> 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? :)
> 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
--
Informationen rund um Usenet und Newsserver:
<https://th-h.de/net/usenet/>
> 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.
bereits in der History steht, also das Posting normalerweise bereits
angenommen wurde. Ich wüsste nicht, dass das irgendwo vertieft gelogged
wird; wozu auch? :)
> Da ich ja nur einen feed habe, ist es ziemlich ausgeschlossen dass die
> Nachrichten refused werden weil der server sie schon kennt (oder?).
"rejected" bedeutet, dass er das Posting aus anderen Gründen nicht
annimmt. Das wird in /var/log/news/news gelogged.
-thh
--
Informationen rund um Usenet und Newsserver:
<https://th-h.de/net/usenet/>
smash
Nov 12, 2021, 1:11:58 PM11/12/21
to
Am 12.11.21 um 17:10 schrieb 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
> "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? :)
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
smash
Nov 12, 2021, 1:13:51 PM11/12/21
to
Am 12.11.21 um 14:22 schrieb Daniel Weber:
danke, der hinweis war echt hilfreich! hab zwar die zwei source ips
gesehen aber nicht weiter drueber nachgedacht weil halt via IPv4 und
Ipv6 angebunden (dass da zwei IPv6 Adressen stehen kam mir dann auch
erst spaeter...)
cheers,
smash
gesehen aber nicht weiter drueber nachgedacht weil halt via IPv4 und
Ipv6 angebunden (dass da zwei IPv6 Adressen stehen kam mir dann auch
erst spaeter...)
cheers,
smash
Thomas Hochstein
Nov 12, 2021, 3:00:03 PM11/12/21
to
smash schrieb:
> 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".
Ist die Message-ID schon in der History, kann das bspw. so aussehen:
> IHAVE <ein.a...@message.id>
< 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
aus:
> IHAVE <ein.a...@message.id>
< 335 Send article to be transferred
> [... 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:
| news@weidegrund $ grep '111120210050070073%nospam' /var/log/news/news
| Nov 11 06:50:13.884 + news.karotte.org <111120210050070073%nos...@nospam.invalid> (@[...]@) 1286 inpaths! [...]
| Nov 11 06:50:13.888 - szaf-out.news.weretis.net <111120210050070073%nos...@nospam.invalid> 439 Duplicate
| Nov 11 06:50:13.888 - news.datentrampelpfad.de <111120210050070073%nos...@nospam.invalid> 439 Duplicate
| Nov 11 06:50:13.889 - peer-szaf.out.news.welterde.net <111120210050070073%nos...@nospam.invalid> 439 Duplicate
| Nov 11 06:50:13.894 - szaf-out.feeder.erje.net <111120210050070073%nos...@nospam.invalid> 439 Duplicate
[...]
> 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?
> 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.
> vielen dank, der unterschied refused/rejected war mir nicht klar. btw.
> was meint duplicate?
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".
Ist die Message-ID schon in der History, kann das bspw. so aussehen:
> IHAVE <ein.a...@message.id>
< 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
aus:
> IHAVE <ein.a...@message.id>
< 335 Send article to be transferred
> [... 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:
| news@weidegrund $ grep '111120210050070073%nospam' /var/log/news/news
| Nov 11 06:50:13.884 + news.karotte.org <111120210050070073%nos...@nospam.invalid> (@[...]@) 1286 inpaths! [...]
| Nov 11 06:50:13.888 - szaf-out.news.weretis.net <111120210050070073%nos...@nospam.invalid> 439 Duplicate
| Nov 11 06:50:13.888 - news.datentrampelpfad.de <111120210050070073%nos...@nospam.invalid> 439 Duplicate
| Nov 11 06:50:13.889 - peer-szaf.out.news.welterde.net <111120210050070073%nos...@nospam.invalid> 439 Duplicate
| Nov 11 06:50:13.894 - szaf-out.feeder.erje.net <111120210050070073%nos...@nospam.invalid> 439 Duplicate
[...]
> aber nachrichten die der server rejected tauchen lediglich in der
> statistik auf.
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?
> aber das soll jetzt nicht darueber hinwegtaeuschen dass ich die antwort
> auf meine frage mit ausfuehrlicherem doku lesen vermutlich selber haette
> finden koennen ;)
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.
smash
Nov 12, 2021, 3:44:45 PM11/12/21
to
Am 12.11.21 um 20:49 schrieb 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.
> 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.
> dokumentiert gefunden, wohl aber die Gegenrichtung, d.h. das Logging von
> innfeed. In "man innfeed" steht dann
wird heute meine bettlektuere!
cheers,
smash
> smash schrieb:
>
>> 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! :)
>
>> 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".
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.
> 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
configfile hat seine eigene umfangreiche manpage, finde ich sehr angenehm.
> dokumentiert gefunden, wohl aber die Gegenrichtung, d.h. das Logging von
> innfeed. In "man innfeed" steht dann
cheers,
smash
0 new messages