[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[leafnode-list] Re: How to debug missing (not-fetched) articles?
On Tue, Aug 12 2003, Matthias Andree wrote:
> You mean: applyfilter -c FILE should see if the article in FILE matches
> filters?
Yes.
> What group would applyfilter choose? The first one listed? Try all?
What does leafnode do if an article matches the filter only in group1,
but not in others? I suppose the article is stored only in group2
(and group3, ...)? So I think "Try all" (for all in
$interesting_groups) would be the best.
>> Okay, I changed "debugmode" in leafnode/config to include "Filtering"
>> and "Store", run "applyfilter -vvvvv -D 2233 -n some.group" and grep
>> the output for "regexp filter:.*matched". Done, found the
>> culprit. :-)
>>
>> Is the above really the best method or am I missing something obvious?
>
> Well, filter logging happens at "debug" priority. Two conditions:
[...]
> I agree that this may be a bit too strict.
>
> What modifications to this scheme would you suggest?
Your patch is a good basis, as it confirms that the article indeed was
filtered by leafnode and it gives me the MID.
> Log at LOG_INFO priority rather than LOG_DEBUG?
I don't have strong preferences concerning this. The main problem is
that filter/store debugging gives too much output.
> Print filter line numbers to ease identification of the filter line?
Yes, would be nice to have.
> There should indeed be an easy way for the user to enable a "what
> filter ate my news" option.
Yes. My initial idea was to extend applyfilter, because it probably
already does most of the task. But a combination of "MID-Logging",
"fetchnews -M" (this step should be eliminated) and "applyfilter -c"
is okay. But it should be a simple command.
- "MID-Logging": Confirms that it has been filtered
- "fetchnews -M": Get article by MID. It would be good to be able to
eliminated this step.
- "applyfilter -c" with `special' output level and restricted to a
specified MID, group+number, path/to/article or stdin. (The latter
would be sufficient for me.)
Concerning `special' output level: -c should produce an output like
"article NNN <MID> rejected by filter (XOVER), line X in
/path/to/filter" or similar, without other `noise' (debugging
output). More debugging output could be added when
additional/several -v are given on the command line.
A stdin-option for "applyfilter -c" would be nifty in Gnus (or other
newsreaders): Use `^' or `j' to get the article and pipe (`|') it to
"applyfilter -c" and see why it has been filtered.
> I'm attaching a gzipped update patch that bumps Message-ID logging
> to INFO priority
One remark (maybe that's not obvious for others): Simlilar to what you
mentioned about news.debug, I had to add "news.info
-/var/log/news/news.info" to /etc/syslog.conf to see those messages in
the logs (SuSE 8.2).
> and makes the filter logging more uniform (you can grep for
> "rejected by filter" or, when debugmode is enabled, egrep for
> "rejected|matched"). Also see the new "LOGGING" section of man 5
> filterfile.
Thank you very much! Very nice.
While at it...
| article 93007 <MID> rejected by filter (XOVER)
Okay this was filtered on subject ==> XOVER
| store: article <00005fe70a0b$00006df0$00004c95@xxxxxxxxxxx> rejected
| by filter
I'm quite sure that it's this rule (though I didn't debug it):
,----
| newsgroups = gmane\..*
| # Detected spam is crossposted to gmane.spam.detected...
| pattern = ^Xref:.* gmane\.spam\.detected:
| action = -5000
`----
Why "store" and not "XOVER" here? Does this mean, that the article
header has been fetched?
| Xref: main.gmane.org gmane.comp.graphics.gnuplot.devel:18 gmane.spam.detected:113141
I'm using leafnode-2.0.0.alpha20030731a plus your patch from
yesterday. Is this okay or shouldn't it be filtered at "XOVER" level?
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- PGP key available via WWW http://rsteib.home.pages.de/
--
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list