Detailled innfeed logging?
cbiedl at gmx.de
Sat Jan 28 12:35:34 UTC 2006
Bill Davidsen wrote...
[ no need to Cc: me, I do read the list ]
> If you want to do it "right" you want a status of accepted, rejected,
> refused, pushed back, dropped, etc, for every article offered to every
> peer... I have the feeling that in many cases the logs would need more
> space than the articles and the overhead of formatting would be
If you're feeding a zillion sites you'll need the space for backlog
anyway. But the have-dozen-peers site has no need to be afraid: The
per-site log file would have about the same size as the news log file
itself. And Disk space is not that expensive any more. Furthermore I was
not talking of enabling such an option per default. I'd like to have it
at all in a debugging situation like the one that caused my inital
A site had trouble feeding certain articles, there were received like in
| Jan 24 04:00:13.592 + peerC <msg at id> 1234 (...) peerB (...)
There's no backlog to peerB but the article arrived at peerB three days
later, after a short detour via Russia and Australia. Nothing in the
logs of peerB. How would I debug that?
> I presume you have something more than "log hell out of everything" in
> mind, sharing that would get you some feedback, but my first thought is
> that I couldn't afford to have it on all the time, if I did it would be
> expensive to parse, and if I know enough to turn it on for one site at
> the right time, I can probably catch what I need with a sniffer or tcpdump.
tcpdump is an excellent tool for short debuggings but plain nightmare
for that. At first it requires root privileges which I do not have on
all systems. Then it will create a huge dump file with a lot of
uninteresting content: The body of the messages, the -s option is not a
safe cure against that problem. And finally I'll need other tools to
gain grep'able Information.
More information about the inn-workers